View ZR36060_130795.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

Integrated JPEG CODEC
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 ............................................1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
The ZR36060 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 The ZR36060 and the JPEG Standard . . . . . . . . . . . . . . . . . . . . . . . 3
JPEG baseline overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 JPEG markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Motion JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
ZR36060 Functional States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 The SLEEP State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Loading Parameters and Tables . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Data Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Data Flow in Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Data Flow in Decompression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Compression and Decompression Modes . . . . . . . . . . . . . . . . . . . .23 Compression Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Data Corruption during Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Notational Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Pin Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Video Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Video Syncs - Master and Slave Modes. . . . . . . . . . . . . . . . . . . . . . 8
Master mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Slave mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Statistical Compression Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Auto Two-Pass Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Tables-Only Compression Pass. . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Decompression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Data Corruption during Decompression . . . . . . . . . . . . . . . . . . . . . . . . . 26
Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Video stream sampling and cropping . . . . . . . . . . . . . . . . . . . . . . 10
The PVALID control signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Power Management and Power-up . . . . . . . . . . . . . .27 Register and Memory Description . . . . . . . . . . . . . .28
General Control Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 ID and Testing Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 Video Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 JPEG Marker Segments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Video Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Horizontal down-scaling in compression . . . . . . . . . . . . . . . . . . . . . . . . .11 Vertical down-scaling in compression . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Horizontal up-scaling in decompression . . . . . . . . . . . . . . . . . . . . . . . . .11 Vertical up-scaling in decompression . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Active Area Size Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Spatial Mix of Video Streams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Host Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Interrupt Request and Associated Registers . . . . . . . . . . . . . . . . . 15
Code Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Master Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Slave Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Host abort of a code read or write cycle. . . . . . . . . . . . . . . . . . . . . . . . . .18 Data alignment in Code Slave mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Transition between fields in compression . . . . . . . . . . . . . . . . . . . . . . . .19 Transition between fields in decompression . . . . . . . . . . . . . . . . . . . . . .20
Electrical Characteristics . . . . . . . . . . . . . . . . . . . . . .35 Absolute Maximum Ratings. . . . . . . . . . . . . . . . . . . .35 Operating Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . .35 AC Timing Specifications . . . . . . . . . . . . . . . . . . . . .36 Mechanical Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
i
ii
ZR36060
PRELMINARY
INTEGRATED JPEG CODEC
FEATURES
s Single-chip JPEG processor which integrates all the modules needed for JPEG encoding and decoding: - Raster-to-block and block-to-raster converter - Strip buffer - JPEG codec s Motion video compression and expansion capability: - Up to 25 frames/sec, square pixel and CCIR PAL - Up to 30 frames/sec, square pixel and CCIR NTSC s Three modes of Bit Rate Control (BRC): - Auto Two Pass: for still image compression, produces tightly controlled compressed data file size - Single pass: for motion video compression, keeps the file size approximately fixed - No BRC: uses fixed quantization tables s Glueless interface to common video decoders (e.g., Philips, Brooktree, Samsung, ITT, Harris) s Glueless interface to the ZR36057, I32 and other common multimedia controllers. s Supports 8 and 16-bit YUV video interfaces s Supports master and slave modes of video synchronization s Interfaces to a variety of host controllers, ranging from the dedicated high-performance ZR36057 PCI controller to generic low-cost microcontrollers s Flexible compressed data interface: - 8-bit master mode, supporting transfer of up to 30 Mbytes/ sec - 16-bit slave mode, supporting transfer of up to 16.7 Mbytes/sec - 8-bit slave mode, supporting transfer of up to 8.3 Mbytes/ sec s On-chip video processing, including: - Mixing of two video sources - Horizontal (1:2 and 1:4) and vertical (1:2) up and down scaling - Cropping in compression and programmable background color in decompression s 3.3V power supply with 5V-tolerant I/O s Low power consumption: - 850 mW at 30 MHz operating frequency - Power down mode for power saving s 100-pin PQFP package
APPLICATIONS
s Desktop video editing subsystems s PCMCIA video capture cards s Digital still cameras s Digital video recording s JPEG-based video conferencing systems
Video Decoder
Video Encoder
Audio Control Audio FIFO Graphics Sub-System
Audio Codec
ZR36057
ZR36060
PCI Bus
Figure 1. JPEG-based video editing subsystem for PCI Systems
ZORAN Corporation
s
1705 Wyatt Drive
s
Santa Clara, CA 95054
s
(408) 986-1314
s
FAX (408) 986-1240
January 1997
Integrated JPEG CODEC Integrated JPEG CODEC
Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
The ZR36060 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 The ZR36060 and the JPEG Standard . . . . . . . . . . . . . . . . . . . . . . . 3
JPEG baseline overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 JPEG markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Motion JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
ZR36060 Functional States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The SLEEP State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading Parameters and Tables . . . . . . . . . . . . . . . . . . . . . . . . . . Data Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 21 21 21 22
Data Flow in Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 Data Flow in Decompression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Notational Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Compression and Decompression Modes . . . . . . . . . . . . . . . . . . . 23 Compression Pass. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Data Corruption during Compression . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Pin Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Video Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Video Syncs - Master and Slave Modes. . . . . . . . . . . . . . . . . . . . . . 8
Master mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Slave mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Statistical Compression Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . . Auto Two-Pass Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tables-Only Compression Pass. . . . . . . . . . . . . . . . . . . . . . . . . . . Decompression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24 24 24 25
Data Corruption during Decompression. . . . . . . . . . . . . . . . . . . . . . . . . .26
Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Video stream sampling and cropping . . . . . . . . . . . . . . . . . . . . . . 10
The PVALID control signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Power Management and Power-up . . . . . . . . . . . . . 27 Register and Memory Description . . . . . . . . . . . . . . 28
General Control Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ID and Testing Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Video Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . JPEG Marker Segments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 30 31 33
Video Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Horizontal down-scaling in compression . . . . . . . . . . . . . . . . . . . . . . . . 11 Vertical down-scaling in compression . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Horizontal up-scaling in decompression . . . . . . . . . . . . . . . . . . . . . . . . . 11 Vertical up-scaling in decompression . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Active Area Size Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Spatial Mix of Video Streams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Host Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Interrupt Request and Associated Registers . . . . . . . . . . . . . . . . . 15
Code Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Master Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Slave Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Host abort of a code read or write cycle . . . . . . . . . . . . . . . . . . . . . . . . . 18 Data alignment in Code Slave mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Transition between fields in compression. . . . . . . . . . . . . . . . . . . . . . . . 19 Transition between fields in decompression . . . . . . . . . . . . . . . . . . . . . . 20
Electrical Characteristics . . . . . . . . . . . . . . . . . . . . . Absolute Maximum Ratings . . . . . . . . . . . . . . . . . . . Operating Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . AC Timing Specifications . . . . . . . . . . . . . . . . . . . . .
35 35 35 35 36
Mechanical Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2
Integrated JPEG CODEC
1.0 INTRODUCTION
1.1 The ZR36060
The ZR36060 is an integrated JPEG codec targeted to video capture and editing applications in desktop and laptop computers. Figure 1 shows an example of a typical application, a video editing subsystem for PCI bus computers. The ZR36060 integrates the functionality of a JPEG codec such as the ZR36050, a raster-to-block converter such as the ZR36015, as well as the strip buffer SRAM for the raster-to-block converter and additional functions. It is based on the field proven, fully compliant Zoran JPEG device technology, and incorporates Zoran's patented bit rate control mechanism. In compression, the ZR36060 accepts YUV 4:2:2 digital video, performs optional cropping and decimation, and encodes it into a JPEG baseline compressed bitstream, which it outputs to a host controller. In decompression, it receives the bitstream from the host controller, decodes it back to YUV 4:2:2 format digital video, up-scales it if required, and outputs the video to a composite video encoder or other destination. The ZR36060 incorporates hardware support for multiplexing two video sources (in rectangular windows) in compression, or the reconstructed video with another source in decompression. It can operate as a video sync master or slave, with 8-bit or 16bit video bus widths. A pixel flow control mechanism is provided for convenient implementation of non-real-time video rates, such as for still picture compression.
VSYNC HSYNC FI BLANK PVALID SUBIMG POE Y[7:0] UV[7:0] VCLK VCLKx2
The code interface of the ZR36060 can operate in 8-bit master, 8-bit slave or 16-bit slave modes. In slave mode, code transfer shares the host interface, which is generic enough to be able to interface gluelessly with a variety of host controllers, ranging from the dedicated, high performance ZR36057 to common microcontrollers. The ZR36060 is a CMOS device, requiring a 3.3 Volt power supply. Its inputs and outputs are 5 Volt tolerant. A power-down ("sleep") mode reduces current consumption to a very low level, while preserving the logic state of the device. A block diagram of the ZR36060 is shown in Figure 2.
1.2 The ZR36060 and the JPEG Standard
The JPEG standard, ISO/IEC 10918-1, defines a whole range of options for compressing continuous-tone images - a baseline lossy compression process, extended lossy processes, lossless compression, and hierarchical compression methods. The ZR36060 implements the baseline process. Even the baseline method is defined by the JPEG standard to provide maximal flexibility in choosing the color space in which an image is compressed - an image can have an almost unlimited number of color components, and these can be compressed in a single scan, or in multiple scans. Because its main targeted application is motion color video compression and decompression, the architecture of the ZR36060 supports one particular subset: Since the ZR36060 supports only the YUV 4:2:2 pixel format, it supports three color components, in a single interleaved scan.
PLL & Clocks
Video Interface Internal Configuration Memory (1K x 8 bits) (Registers, Markers, Tables)
1.2.1 JPEG baseline overview
The JPEG baseline compression method is based on the discrete cosine transform or DCT. The DCT is performed on 8x8 blocks of samples, of each color component, resulting in a set of 64 DCT coefficients for each block. Thus, in order for a normal raster-scanned image to be compressed, it must first be converted to block format This requires that an 8-line strip of the image (containing 8 lines of each color component) be stored in a strip buffer, so that the samples can be re-ordered (see Figure 2). For subsequent stages of the compression, the 64 DCT coefficients of each block are further re-ordered by scanning the block in a zig-zag sequence. Each of the 64 coefficients is quantized using the appropriate value from a 64-entry quantization table. In the ZR36060, it is possible to define three different quantization tables, one per color component; generally, however, two tables are used, one for the luminance component and one for the chrominance component. The quantized DCT coefficients are passed to a Huffman encoder, for the final stage of the process. The Huffman coding is performed separately for the DC coefficient of each block (the first coefficient of the block), and the remaining 63 AC coeffi-
RTBSY DATERR
Strip Memory START FRAME END EOI COMP SLEEP RESET
JPEG CODEC Control CODE FIFO (512 x 8 bits)
CCS COE CWE CBUSY CODE [7:0]
CODE and Host Interface
ADDR[1:0] JIRQ ACK CS WR RD DATA[7:0]
Figure 2. ZR36060 Block Diagram
3
Integrated JPEG CODEC
cients. The encoding methods used for DC and AC coefficients differ in their details, and this requires two Huffman tables to be specified, one for DC and one for AC. And since the statistics of the luminance and chrominance components are generally quite different, separate Huffman tables are required for luminance and chrominance, for a total of four tables, two DC and two AC. The ZR36060 supports this configuration. Baseline decompression essentially consists of the inverses of each of the stages used in compression, in reverse order: Huffman decoding, dequantization, inverse DCT, and conversion of the blocks back to raster order. In all three of the formats, the tables and the parameters required for decoding the image and/or the tables are contained in marker segments, which are sequences of bytes that start with special two-byte codes called markers or marker codes. The two bytes that follow the marker specify the length of the marker segment in bytes, including the two length bytes but not including the marker code itself. There are two special stand-alone markers that are not associated with marker segments, to mark the startof-image (SOI) and end-of-image (EOI). The code values are 0xFFD8 for SOI, and 0xFFD9 for EOI. The first byte of every marker is 0xFF. A marker may be prefixed by an arbitrary number of 0xFF bytes which are discarded by the decoder. The second byte of a marker has defined values, except for 0x00, which is used as follows. In order to permit a decoder to identify the restart markers, if they exist, and the EOI marker, the encoder stuffs a 0x00 byte after every 0xFF byte that results from the Huffman encoding. Note that this "byte stuffing" is an essential part of the JPEG standard, and there is no definition in the standard of a bitstream that does not include the byte stuffing. The ZR36060 always produces image bitstreams with byte stuffing, and requires the byte stuffing to be present in order to decode a JPEG bitstream. The JPEG standard also does not define any sort of "markerless" bitstream data format. Certain markers and marker segments are defined in the standard to be "required", and others, such as the restart markers and the table marker segments, are optional. The ZR36060 always includes the required markers when it produces a compressed bitstream, and can be programmed to include certain optional markers. To be decompressed by the ZR36060, an image bitstream must include the required markers. All markers included in the bitstream, required and optional, are handled automatically, without host intervention, by the ZR36060 in decompression.
1.2.1.1 The Minimum Coded Unit
If the compressed image data is interleaved, as is the case in the ZR36060, the compression is performed in units of a Minimum Coded Unit, or MCU, which contains one or more blocks of each color components. For the 4:2:2 pixel format used by the ZR36060, where the chrominance (U and V) components are decimated by 2:1 horizontally relative to the luminance (Y), the MCU consists of 2 blocks of Y followed by one block each of U and V.
1.2.1.2 Restart Intervals
The ZR36060 supports compression and decompression of JPEG data that includes restart intervals. A restart interval is defined as an integral number of MCUs, which are processed as an "independent sequence", meaning that it is possible to identify and decode a restart interval within a JPEG data sequence, without the need to decode whatever data precedes it. In the context of baseline compression, this has significance because the DC coefficients of the DCT are differentially encoded. Note that the use of restarts is optional; it is acceptable (and very common) to use no restart markers and encode the whole image as a single sequence.
1.2.2.1 Required markers and marker segments 1.2.2 JPEG markers
JPEG defines three data formats for the compressed bitstream, all of which are supported by the ZR36060: * The interchange format, which contains the specifications of all the tables required to decode the image. * the abbreviated format for compressed data, which can contain some or none of the tables, under the assumption that the remaining tables are known to the decoder and are already loaded in the decoder or can be loaded. This is commonly used for motion video, in order to save the time otherwise required to decode the tables from their specifications. * the abbreviated tables-only format, which contains no compressed data but only tables. It is one means by which it is possible to load tables into the decoder; in the ZR36060 the other means is by specifying the tables to the device and issuing an explicit Load command. The required markers for baseline JPEG are: * Start-of-image, SOI (0xFFD8). This is the first marker in a JPEG image bitstream. * Start-of-frame marker segment, SOF0 (0xFFC0), followed by a variable number of bytes depending on the number of color components. For the ZR36060, there are always three components and the segment has a length of 17 bytes. The SOF segment is used to specify which quantization table to use for each color component, and the number of blocks of each color component in the MCU. * Start-of-scan marker segment, SOS (0xFFDA), followed by a variable number of bytes depending on the number of color components. The Huffman coded data follows immediately after the last byte of the SOS segment. In the case of the ZR36060, the length of the SOS segment is always 12 bytes. The SOS segment is used to specify which Huffman table to use for each color component.
4
Integrated JPEG CODEC
* End-of-image, EOI (0xFFD9). This marker follows the last byte of the compressed data. In compression, the ZR36060 inserts optional marker segments, if programmed to do so, into the compressed data bitstream in a fixed order: APP, COM, DRI, DQT, DHT. These appear immediately after SOI, before SOF. In decompression, they can appear in any order or position allowed by the JPEG standard.
1.2.2.2 Optional markers and marker segments
The ZR36060 supports the following optional markers and segments: * Application specific, APPn (0xFFE0-0xFFEF). The standard allows up to 16 different APP markers in a single image bitstream. The ZR36060 can insert one APP marker in compression. A ZR36060 APP marker can have a segment length of up to 62 bytes. In decompression, if the image bitstream contains a single APP marker with a segment length of 62 bytes or fewer, the host can retrieve it after the ZR36060 has finished decompressing the image; if the segment is longer, the data is lost. If there are multiple APP segments, only the last one can be retrieved. * Comment, COM (0xFFFE). The restriction on the length (62 bytes) is the same as for the APP marker. * Define restart interval, DRI (0xFFDD). Defines that restarts are to be used, and the size in MCUs of the restart interval. * Define quantization tables, DQT (0xFFDB). Specifies the quantization tables used to compress the image. * Define Huffman tables, DHT (0xFFC4). Specifies the Huffman tables used to compress the image. * Restart, RSTm (0xFFD0-0xFFD7). Marks the beginning of a restart interval in the compressed data. Note that when quantization and Huffman tables are loaded into the ZR36060 by the host controller, they are specified in exactly the same format as is used in the marker segments.
1.2.3 Motion JPEG
The JPEG standard defines a method for compression of a single ("still") image. It does not have any provision for motion video, and the term "motion JPEG" simply means that each field of a video sequence is compressed as a separate JPEG image bitstream. The ZR36060 includes features that make this procedure straightforward.
1.3 Notational Conventions
The following notational conventions are used in this data sheet: External signals: bold capital letters (e.g., COMP) Active-low mark: overbar (e.g., RESET) Buses: XXmsb_index:lsb_index (e.g., UV7:0) Register fields: XXmsb_index:lsb_index (e.g., Count27:16) Register types: * R - read only * W - write only * RW - read-write (data written can be read back) Numbers: numbers with no prefix or suffix are decimal (e.g., 365, 23.19). Hexadecimal numbers are indicated with a `0x' prefix (e.g., 0xB000, 0x3). Binary numbers are indicated with a `b' suffix (e.g., 010b, 0000110100011b).
5
Integrated JPEG CODEC
2.0 PIN DESCRIPTION
The ZR36060 is supplied in 100-pin PQFP package. The following table lists the pins of the device and provides a concise functional description of each.
Table 1: Pin Descriptions
Symbol Type Description Code/Host Port (26 pins) CODE[7:0 ] I/O Code bus. In Code Master mode, this 8-bit bidirectional bus is used to read (write) the compressed data from (to) an external code FIFO. In 16-bit Code Slave mode, this is used as an extension (the MSB) of the DATA bus. During and after RESET this bus is floating, with internal pull-ups. Code Chip Select, used only in Code Master mode. This active-low output signal acts as a chip select signal from the ZR36060 to the external code FIFO. CCS goes active at the start of a read or write cycle and remains active throughout the cycle. CCS remains active continuously in back to back read or write cycles. During and after RESET this pin is logic high. Code Read (output enable), used only in Code Master mode. This active-low output signal acts as a read strobe signal from the ZR36060 to the external code FIFO. COE goes active 0.5 VCLKx2 cycles after start of a read cycle. The CODE bus input is latched on the rising edge of COE. During and after RESET this pin is logic high. Code Write, used only in Code Master mode. This active-low output signal acts as a write strobe signal from the ZR36060 to the external code FIFO. CWE goes active 0.5 VCLKx2 cycles after start of a write cycle. CODE bus data is valid throughout the strobe pulse and permits the external code FIFO to latch the data on the rising edge of CWE During and after RESET this pin is logic high. Code FIFO Busy. When the ZR36060 is the master of the code bus CBUSY is an active-low input, used by the external code FIFO controller to temporarily halt the transfer of compressed data. When the ZR36060 is the slave of the code bus CBUSY is an active-low output. It is asserted (low) by the ZR36060 to indicate the internal code FIFO cannot be accessed, due to an empty/full condition (for compression/decompression modes respectively). On deassertion, CBUSY is driven high for one internal clock and then released to a floating condition (needs external pullup). When the ZR36060 is connected to the ZR36057, CBUSY is connected to the CBUSY input of the latter. During and after RESET his pin is floating (input mode). Data bus. This 8-bit bidirectional bus is used to read/write to the internal memory of the ZR36060. In Code Slave mode, it is also used to transfer the compressed data. In 16-bit Code Slave mode, the CODE bus is used as an extension of the DATA bus. During and after RESET this bus is floating with internal pullup. Address bus. This 2-bit bus is used by the host to access the code register (in Code Slave mode), or the indirect address/data register which maps the 1Kbyte internal memory array of the ZR36060. Chip Select. This active-low input signal acts as a chip select signal from the host to the ZR36060. Write. This active-low input signal acts as a write pulse from the host to the ZR36060. The DATA (with CODE extension in 16bit Code Slave mode), is latched on the rising edge of WR. Read. This active-low input signal acts as a read pulse from the host to the ZR36060. The DATA (with CODE extension in 16bit Code Slave mode), is enabled as an output during the RD pulse so the host can latch the ZR36060 data on the rising edge of RD. Acknowledge. Used by the ZR36060 to notify the host that the current read or write strobe pulse can be completed. During code access (Code Slave mode), the ZR36060 will not issue an ACK if the internal code FIFO is empty/full (in compression/decompression respectively). On deassertion, ACK ist driven high for 1 VCLKx2 cycle and then released to a floating condition (needs external pull-up). During and after RESET this pin is floating (logic high with pullup).
CCS
O
COE
O
CWE
O
CBUSY
I/O
DATA[7:0]
I/O
ADDR[1:0 ] CS WR RD
I I I I
ACK
O
Video Port (25 pins) Y7:Y0 I/O In 16-bit video mode (Video8==0), these lines are the Luminance video lines. In 8-bit mode (Video8==1) these lines are luminance/chrominance lines, multiplexed in time according to the CCIR656 component order. In compression these lines are inputs, while in decompression they are outputs. During and after RESET this bus is floating with internal pullup.
6
Integrated JPEG CODEC
Table 1: Pin Descriptions (Continued)
Symbol UV7:UV0 Type I/O Description In 16-bit video mode (Video8==0), these lines are the chrominance video lines. In compression these lines are inputs, while in decompression they are outputs. In 8-bit mode (Video8==1) these lines are not used: in compression they are ignored (inputs), and in decompression they are floating. During and after RESET this bus is floating with internal pull-ups. Main Video Clock input. The video interface of the ZR36060 is synchronized by this clock. Digital video bus clock enable. Used as a qualifier of the video bus data. Must be synchronized and toggling at half the frequency of VCLKx2, in both 8 and 16-bit video bus width modes. Horizontal sync. When the ZR36060 is slave (SyncMstr==0), HSYNC is input, and when it is the sync master (SyncMstr==1) HSYNC is an output. During and after RESET this pin is floating (input mode). Vertical sync. When the ZR36060 is slave (Syncstr==0), VSYNC is input, and when it is the sync master (SyncMstr==1) VSYNC is an output. During and after RESET this pin is floating (input mode). Digital video bus field indicator (odd/even). When the ZR36060 is the master of the video bus FI is an output, otherwise it is an input. The polarity of FI, as input or output, is set by FiPol. During and after RESET this pin is floating (input mode). Digital video bus composite blank output. Active only when the ZR36060 is the sync master of the video bus, otherwise the pin is floating. The horizontal and vertical blanking areas are programmable. During and after RESET this pin is floating with internal pullup. When the ZR36060 is in compression mode, this input is used as an additional qualifier (other than VCLK) of the video data signals and the sync signals. An active level sampled on this signal at the time when a pixel is sampled, indicates that this is a valid pixel. This input is meant to be connected to the PXEN output of the ZR36057. When the ZR36060 is in decompression mode, this input is used by the recipient of the video to stall the video stream of the ZR36060. A non-active level sampled on this signal will cause the ZR36060 to continue to output the current pixel instead of proceeding to the next one. Once PVALID is sampled active again the normal pixel sequence resumes. If the ZR36060 is the video sync master, then PVALID not active will freeze the internal sync generator. The polarity of PVALID can be programmed. This output dynamically indicates the boundaries of a sub-image rectangle within the main input or output field size. When the pixels within the programmable rectangle are output/input, SUBIMG is active. For a sub-line of consecutive pixels within the rectangle, SUBIMG is continuously active. The polarity of SUBIMG is programmable. SUBIMG may be connected to the FEIN input of the SAA7110/11, or the read-enable input of a line buffer, FIFO, etc., to permit pixel-by-pixel video mixing during compression and decompression. During and after RESET this pin is logic high. Pixel Output Enable. Used to disable the video bus during decompression, to permit pixel-by-pixel video mixing of the ZR36060 video output with another source. It can be directly connected to the SUBIMG output, or to other suitable control.
VCLKx2 VCLK HSYNC
I I I/O
VSYNC
I/O
FI
I/O
BLANK
O
PVALID
I
SUBIMG
O
POE
I
Control & Status (10 pins) RESET SLEEP I I Reset. When this input is asserted the ZR36060 goes into its RESET state. When it is deasserted all state machines are in IDLE mode and registers contain their default values. RESET must be active for at least 8 VCLKx2 cycles. Power-down mode. When this input is active (low), the ZR36060 goes into its SLEEP (power-down) mode, discontinuing all chip operation and consuming minimal supply current. This pin also initiates coarse locking of the internal PLL to the VCLKx2 frequency. It must be toggled at least once after RESET. SLEEP must remain low for at least 8 VCLKx2 cycles. End of process indication. This active-low output signal indicates completion of a field compression/decompression process. During and after RESET this pin is logic low. End-of-image marker indication. This active-low output signal indicates the last code byte, or word (FFD8 code) is being output or input. EOI is deasserted together with the deassertion (rising edge) of END upon beginning of the next field process. During and after RESET this pin is logic low. Start compression/decompression command input. When the ZR36060 is in IDLE state, it looks for an active low level on this input in order to start compression or decompression. Once the active level is sampled the ZR36060 will start compression or decompression with the next VSYNC or with the next odd VSYNC (depending on the FRAME input). To be detected correctly, START must remain low for at least 2 VCLKs. When the ZR36060 is connected to the ZR36057, this input must be connected to a GCS output of the ZR36057. This input is sampled by the ZR36060 together with the START input. When START is sampled active, then if FRAME is also active the ZR36060 will start compressing/decompressing at the next odd field. Otherwise it will start with the next field.
END EOI
O O
START
I
FRAME
I
7
Integrated JPEG CODEC
Table 1: Pin Descriptions (Continued)
Symbol DATERR Type O Description This output is asserted when there is a data corruption event. It is deasserted together with the deassertion (rising edge) of END upon beginning of the next field process. On deassertion, DATERR is floating (needs external pull-up). During and after RESET this pin is floating (logic high with pullup). In compression this output signal indicates a "nearly full" condition in the internal raster-to-block memory ("strip" buffer). This condition occurs when the strip buffer is 16 (or fewer) pixels away from an overflow condition. In decompression RTBSY indicates that the strip buffer is nearly empty, i.e., during every 8*n line of video there are enough blocks to display the next video line. Otherwise an underflow condition occurs. In IDLE state RTBSY is not asserted. If while RTBSY is asserted a data corruption event occurs (overflow or underflow), RTBSY continues to be asserted together with DATERR until the beginning of the next field process (deassertion of END). If no data corruption occurs, RTBSY is deasserted as soon as the almost-overflow/underflow condition is no longer true. RTBSY is meant to be connected to the RTBSY input of the ZR36057. During and after RESET this pin is a logic high. Interrupt request (active low). This output signal requests an interrupt from the host controller, if an interrupt request is enabled and one of the events associated with interrupts occurs. It is deasserted if the host responds to the interrupt by reading the interrupt status register, or if the host disables the interrupt, or upon a reset to the ZR36060. On deassertion JIRQ is floating (needs external pull-up). When JIRQ is active, the START signal is disregarded. During and after RESET this pin is floating (logic high). Compress/Decompress. This output signal provides an indication of the current operating mode of the ZR36060. When it is high, the ZR36060 is in the compression mode; when it is low, the ZR36060 is in the decompression mode. During and after RESET this pin is a logic high.
RTBSY
O
JIRQ
O
COMP
O
Power Signals GND VDD NC Ground Power supply (3.3V) Non-connect pins (reserved).
3.0 VIDEO INTERFACE
The video interface of the ZR36060 is highly configurable, to facilitate a glueless connection to most video decoders, encoders, MPEG decoders, frame memory controllers, graphics accelerators, etc. * BLANK - Composite blanking The parameters that configure the sync generator when the ZR36060 is a sync master are (see Figure 3): * Vtotal - Total number of lines per frame (e.g.- for NTSC, 525 video lines) * Htotal - Total number of VCLKs (pixels) per line (e.g.- for CCIR NTSC, 858 pixels) * VsyncSize - Length of the VSYNC pulse measured in lines * HsyncSize - Length of HSYNC pulse measured in VCLKs * BVstart - Length (in lines) from VSYNC to first non-BLANK line. * BVend - Length (in lines) from VSYNC to last non-BLANK line. * BHStart - Length (in pixels) from HSYNC to first non-BLANK pixel. * BHend - Length (in pixels) from HSYNC to last non-BLANK pixel. * VSPol - Polarity of the VSYNC signal * HSPol - Polarity of the HSYNC signal * FIPol - Polarity of the FI signal * BlPol - Polarity of the BLANK signal
3.1 Video Syncs - Master and Slave Modes
The ZR36060 supports two video sync source modes: * Sync Master - the ZR36060 internally generates all the video timing signals. * Sync Slave - the ZR36060 synchronizes itself with an external video source. The 1-bit SyncMstr parameter selects the mode. Normally, in compression the ZR36060 would be slaved to the output of a video decoder, but not necessarily; for example, the ZR36060 could control a frame memory in Sync Master mode.
3.1.1 Master mode
When configured as a sync Master, the ZR36060 drives the following signals: * HSYNC - Horizontal sync * VSYNC - Vertical sync * FI - Even/Odd field indication
8
Integrated JPEG CODEC
* FIVedge - Defines at which VSYNC edge the FI signal changes state (leading or trailing edge). This is also the reset point for the vertical counters, indicating the end of the previous field and the beginning of a new field. After the parameters are properly initialized and loaded (using the Load command), the sync generator is free running, and is not affected by the state of the JPEG codec. The SyncRst register bit resets the sync generator counters and the PVALID signal can temporarily freeze the counting and sync signals.
BHend BHstart BLANK HsyncSize HSYNC BVstart BVend VsyncSize Htotal ODD Field EVEN Field Vtotal FI ODD Field (Fields (1, 3, 5...) HSYNC VSYNC
* Internal detection (FIExt = 0), derived from latching the state of HSYNC at each VSYNC. This is useful when using the ZR36060 with video sources that do not provide a dedicated field indication signal. Odd fields are those where the VSYNC edge latches the HSYNC during its short sync period, while on even fields the VSYNC edge latches the HSYNC in the middle of the line (see Figure 4). The VSYNC edge (leading or trailing) used to latch the HSYNC signal can be programmed by means of the FIVedge parameter. Changing FIDet will change the even/odd interpretation. Note: the HSYNC edge must precede the latching VSYNC edge by at least 2 VCLKs for reliable latching.
FI
BLANK
VSYNC
HSYNC VSYNC FI EVEN Field (Fields (2, 4, 6...)
Note: In this example VSPol = HSPol = FIPol = BlPol = FIVedge = 0.
Figure 3. Video Sync Generation
3.1.2 Slave mode
When configured as a sync Slave, the ZR36060 samples the following signals: * HSYNC - Horizontal sync * VSYNC - Vertical sync * FI - Even/Odd field indication The parameters Vtotal, Htotal, VsyncSize, HsyncSize, BVstart, BVend, BHstart, BHend, BlPol, FIPol are not used in Slave mode. VSPol, HSPol, FIDet and FIVedge are used as follows: * VSPol - Polarity of the VSYNC input signal. * HSPol - Polarity of the HSYNC input signal. * FIDet - Exchange the even/odd field interpretation after detection. (detection can be accomplished in two ways according to the FIExt parameter, see below) * FIVedge - Defines the reset point for the vertical counters indicating the end of the previous field and the beginning of a new field. When FIExt = 0 it also defines the proper VSYNC edge used to latch HSYNC to internally detect the even/odd field. The field detection can be accomplished in two ways depending on the FIExt parameter (see Figure 4): * External indication by means of the FI signal (FIExt = 1), toggling at the VSYNC rate, indicating whether the current field is even or odd. The polarity of FI is programmable, using the FIPol parameter, while the even/odd interpretation can be exchanged using the FIDet parameter.
Note: VSPol = HSPol = FIPol = FIDet = 0, FIVedge = 1
Figure 4. Field Detection Showing Hor. and Ver. Timing
3.2 Data Formats
When the ZR36060 is configured for 16-bit video bus width (Video8==0), the luminance signal is on Y7:0, and the chrominance signals are multiplexed on the UV7:0 lines (see Figure 5). When operating in 8-bit video bus mode (Video8==1), both the luminance and the chrominance signals are on Y7:0, multiplexed in time according to the CCIR656 recommendation (U=Cb, V=Cr): U0,Y0,V0,Y1,U2,Y2,V2,Y3,.... For 16-bit video, the pixels are sampled on every other rising edge of VCLKx2, which is enabled by VCLK, the video clock qualifier. The polarity of the VCLK qualifier is programmable via the VCLKPol parameter. 8-bit video is sampled using all rising edges of VCLKx2, at twice the pixel rate. Note that 1 pixel length is always 1 VCLK, with both 16-bit and 8-bit video. All internal counters and video events are based on VCLK, that must always be present (at half the frequency of VCLKx2) even when the video interface is configured for 8-bit width. In decompression, the output pixel levels are CCIR601compliant, with values in the [16,235] range. It is possible to override this and let the ZR36060 output the full 256-level scale with the Range parameter bit.
9
Integrated JPEG CODEC
Note that in both 16-bit and 8-bit modes, the ZR36060 does not output, nor expect to receive, control codes indicating timing information, on its YUV video bus.
1 VCLKx2 VCLK 8-Bit Video Interface Y[7:0] BG Color U0 Y0 V0 Y1 U2 Y2 V2 Y3 U4 Y4 VSYNC 16-Bit Video Interface Y[7:0] UV[7:0] BG Color BG Color Y0 U0 Y1 V0 Y2 U2 Y3 V2 Y4 U4 Active Area
Vstart
VSYNC Active Area
Vstart
a) VSPol = 0, FIVedge = 0
2
3
4
5
6
7
8
9
10
11
12 VSYNC Active Area
Vstart
b) VSPol = 0, FIVedge = 1
c) VSPol = 1, FIVedge = 0
VSYNC Active Area
Vstart
Note: 16-bit video is shown with VCLKPol = 0, that is, sampling when VCLK = 0
d) VSPol = 1, FIVedge = 1
Figure 5. Video Data Formats, 8 and 16 bit
Note: The active video area must not overlap the VSYNC pulse. In other words, the active area must always be contained between the trailing edge of VSYNC and the next leading edge.
3.3 Video stream sampling and cropping
Only pixels within an active rectangle are sampled and compressed (in compression) or output (in decompression), as shown in Figure 6. The VSYNC signal indicates the beginning of a new field (the VSYNC edge and polarity are configured by FIVedge and VSPol). The Vstart and Vend parameters determine the first and last lines to be sampled in a field. The leading edge of HSYNC indicates the beginning of a horizontal line (with HSYNC polarity according to HSPol). The Hstart and Hend parameters determine the first and last pixels to be sampled in each line. Further processing such as formatting, scaling and compression is done only to pixels within the active rectangle. In decompression, outside the processed active area rectangle, the video bus outputs a background color, specified by the BackY, BackU, and BackV parameters. Figure 7 and Figure 8 show the relationship of the active area to VSYNC and HSYNC.
HSYNC
Figure 7. Relationship of VSYNC and Active Video Area
HSYNC Active Area Hstart a) HSPol = 0
HSYNC Active Area Hstart b) HSPol = 1
Note: The line counting (for Vstart, Vend) always uses the leading edge of the HSYNC pulse. Hstart is specified from the leading edge of HSYNC. The active video area is allowed to partially overlap the HSYNC pulse. In other words, Hstart could be before or after the trailing edge of HSYNC.
Figure 8. Relationship of HSYNC and active video area
3.3.1 The PVALID control signal
The continuous video stream is usually used by encoders & decoders for `real-time' video capture and playback. However, sometimes it may be desirable to `hold' or not sample the video pixels intermittently, especially when connected to a slow peripheral (such as a host interface compressing a still image, or a memory controller) that cannot cope with the real-time pixel rate. The PVALID signal can be used for this purpose. PVALID acts as a pixel qualifier indicating the presence of `valid' pixels on the bus (similar to the action of VCLK in 16-bit mode). It can interrupt the video stream (in and out) for any period of time with a resolution of VCLK, as shown in Figure 9. VCLK and PVALID differ in that VCLK must always toggle at half the rate of VCLKx2, while PVALID can maintain a continuous level. Only pixels qualified by PVALID that are within the active rectangle area are sampled. PVALID also acts as a `count enable' to the horizontal and vertical counters that implement Hstart, Hend, Vstart, and Vend. For example, after the leading edge of HSYNC
Vstart
Background Color
VSYNC
Vend
Active Area (Rectangle)
Hend Hstart
Figure 6. Video Pixel Stream
10
Integrated JPEG CODEC
the ZR36060 counts Hstart pixels qualified by PVALID, and then samples pixels qualified by PVALID until Hend. The polarity of PVALID is programmable by means of the PValPol parameter.
1 VCLKx2 VCLK HSYNC
2
3
4
5
6
7
8
9
10
11
12
13
8-Bit Video Interface Y[7:0] Input PVALID Y[7:0] Output Horizontal Counter U0 0 Y0 V0 1 Y1 U2 2 Y2 V2 Y3 3 U0 Y0 V0 Y1 Min Width U2 Min Width Y2 V2 Y3
16-Bit Video Interface Y[7:0] Input UV[7:0] Input PVALID Y[7:0] Output UV[7:0] Output Horizontal Counter Y0 U0 0 Y1 V0 1 Y2 U2 2 Y3 V2 3 Y0 U0 Y1 V0 Min Width Y2 U1 Min Width Y3 V2
Notes: 1. HPol = 0; VCLKPol = 0 (sample when VCLK = 0); PValPol = 1 (valid when PVALID = 1). 2. "Horizontal counter" represents an internal counter used to identify the active area. 3. PVALID granularity is one VCLK, in both 8- and 16-bit video interface modes. 4. PVALID may toggle only on a pixel boundary, in this figure when VCLK=0.
Figure 9. Video Data Formats, 8 and 16 bit
3.4 Video Scaling
The ZR36060 incorporates a scaler, that can scale the video in the active area, horizontally and vertically, by simple ratios. It can down-scale the video before it is compressed, and up-scale it after it is decompressed. The result is to permit straightforward implementation of "half screen area" and "quarter screen area" compression. The horizontal down- and up-scaling are accompanied by filtering. Note that this filtering can not be disabled.
3.4.2 Vertical down-scaling in compression
This is specified by the 1-bit VScale parameter: VScale = 0b: No down-scaling VScale = 1b:2:1 decimation, by line dropping In the case of 2:1 vertical scaling, the second, fourth,...etc. lines of the active area of the video field are dropped before the video is compressed.
3.4.3 Horizontal up-scaling in decompression 3.4.1 Horizontal down-scaling in compression
This is specified by the 2-bit HScale parameter. There are three possible configurations: HScale = 00b or 11b: No down-scaling HScale = 01b: 2:1 decimation, with a 3-tap filter HScale = 10b: 4:1 decimation, with a 5-tap filter As in compression, this is specified by HScale: HScale = 00b or 11b: No up-scaling HScale = 01b: 2:1 interpolation HScale = 10b: 4:1 interpolation The interpolated samples are created by weighted-averaging of two neighboring samples.
11
Integrated JPEG CODEC
3.4.4 Vertical up-scaling in decompression
As in compression, this is specified by VScale: VScale = 0b: No up-scaling VScale = 1b:2:1 interpolation, by line replication the Philips SAA7110 video digitizer/decoder); SUBIMG can be used to float this bus while enabling a second video source. Some possible options are to multiplex two video decoders, one decoder and one field memory, one video decoder and one MPEG decoder, etc.
HSYNC
3.5 Active Area Size Restrictions
SVstart
SVend
The maximum allowed size for the active area rectangle is 768 pixels x 64K lines. The ZR36060 JPEG codec always processes an image with dimensions of 2*8*x and 8*y pixels. This is because of the YUV 4:2:2 format, where the MCU is 2 blocks of Y, 1 block of U and 1 block of V. The active area of the video interface must be configured to reflect the dimensions before down-scaling in compression, and after up-scaling in decompression. show the resulting restrictions imposed on the dimensions of the active area.
Source 1
Active Area Rectangle
VSYNC
Source 2
Subimage Rectangle
SHend SHstart
Table 2: Active Area, Horizontal Dimension (HEnd HStart)
Horizontal scaling No scaling (1:1) 2:1 4:1 Multiple of 16 Multiple of 32 Multiple of 64 Restriction
Figure 10. Subimage Parameters In Compression There are several inherent problems in mixing video that the system designer must consider: * The two video sources must be synchronized. This means that pixel clocks, horizontal and vertical timing must come from only one source which is the sync master. * Both video sources must work in the same mode (16-bit or 8bit). * The SHstart and SHend parameters must be such that the boundaries of the subimage rectangle (where SUBIMG changes state) are exactly at the boundary between independent YUV 4:2:2 units (units of two VCLKs, containing related U and V samples) for both sources. To permit video mixing during decompression (playback), the SUBIMG output can be externally connected to the POE input. This way, the ZR36060 places its video data only within (or outside) the rectangle defined by SUBIMG, floating the output video bus outside (or inside) the boundaries (see Figure 11). The polarity of the SUBIMG signal is defined by the SImgPol parameter, and the polarity of the POE signal (to place ZR36060 data inside or outside the rectangle during playback) is defined by PoePol parameter. In Figure 11, the polarity of SUBIMG has been chosen so as to float the video bus outside the subimage rectangle. Note that SUBIMG and POE operate independently of each other, so they can also be used separately.
Table 3: Active Area, Vertical Dimension (VEnd VStart)
Vertical Scaling No scaling (1:1) 2:1 Multiple of 8 Multiple of 16 Restriction
In the internal sampling scheme, the first chrominance sample is always assumed to be a U (Cb) sample. This is directly controlled by the Hstart parameter. Hstart must be programmed to an appropriate value (even or odd) in order for the ZR36060 to sample first the U (Cb) pixel, otherwise U-V inversion occurs.
3.6 Spatial Mix of Video Streams
The ZR36060 is capable of spatially mixing (multiplexing) two video sources for compression, and also of multiplexing the ZR36060 output video with another video source during decompression. The latter is a useful feature for video editing, e.g. to superimpose titles or subtitles onto the images. The SUBIMG output signal creates a sub-image rectangle defined by the SHstart, SHend, SVstart, SVend parameters, where one image is outside and the other one is inside the rectangle (see Figure 10). In compression, this signal can be connected, for example, to two synchronized sources of live video to multiplex their outputs. Some digital video sources have a video bus which can be placed in a floating state (for example,
12
Integrated JPEG CODEC
HSYNC HSYNC
SVstart
SVend
Background Floating Video Bus Subimage Rectangle
VSYNC
ZR36060 Image Display
VSYNC
Active Area Rectangle SHend SHstart Floating Video Bus
Figure 11. Subimage Parameters (w/SUBIMG Wired to POE) In Decompression During decompression, the SUBIMG rectangle is overlaid on the active rectangle. In other words, the video bus will be floating in all the area indicated in Figure 11 regardless of whether the underlying pixels are active or background color (see also Figure 12). The example in Figure 13 shows the result of the spatial mixing of the decompressed video with another video source, as seen by the destination (such as a video encoder). Figure 14 shows the timing of the transitions at the subimage boundaries, for the same typical example in which SUBIMG is used to control POE. The timing of the 16-bit external video source in the example is that of the Philips SAA7110.
Figure 12. Video Bus Output from the ZR36060 in Decompression, Using SUBIMG with POE
HSYNC
Background ZR36060 Image Rectangle
VSYNC
Source 2
Other Source Area
Figure 13. ZR36060 Output Image Multiplexed with Another Source, as Seen by a Video Encoder
13
Integrated JPEG CODEC
1 VCLKx2 VCLK 2 3 4 5 6 7 8 9 10 11 12 13
2 VCLKx2 Y[7:0] from ZR36060 SUBIMG (POE) Y[7:0] External u0 y0 U2 Y2
8-Bit Video Interface V2 Y3 U4 1 VCLKx2
v4
y5
u6
y6
3 VCLKx2 Y[7:0] from ZR36060 UV[7:0] from ZR36060 SUBIMG (POE) Y[7:0] External (SAA7110) UV[7:0] External (SAA7110) Notes: 1. 2. 3. 4. y0 u0
Sampled by SAA7110
16-Bit Video Interface Y2 U2 Y3 V2 1 VCLKx2
Sampled by SAA7110
y1 v1
y5 v4
y6 u6
In this example SImgPol = SImgDat = VCLKPol = 0. In this example SUBIMG is connected to POE to float the ZR36060 video bus. SUBIMG changes state with resolution of one VCLK and at the rising edge of VCLKx2, in both 8-bit and 16-bit mode. In 8-bit mode, the first pixel is enabled 2 VCLKx2 after SUBIMG changes state, and the last pixel is disabled 1 VCLKx2 after SUBIMG changes. 5. In 16-bit mode, the first pixel is enabled 3 VCLKx2 after SUBIMG changes state (this causes the first pixel from the ZR36060 appear on the bus for 0.5 VCLK instead of a complete VCLK period). The last pixel is disabled 1 VCLKx2 after SUBIMG changes, to avoid contention. This timing was chosen to match the characteristics of the SAA7110.
Figure 14. SUBIMG and POE timing during decompression, shown for 8- and 16-bit video
4.0 HOST INTERFACE
The host interface is a generic interface with an 8-bit bidirectional data bus, 2-bit address bus (that indirectly maps a 1Kbyte internal memory space), RD, WR, CS, and ACK pins. It supports glueless interface to most microprocessors, microcontrollers, and buses like the ISA. When the Code interface is configured in Slave mode (see section 5.0 "Code Interface") some of the ZR36060 Host interface pins have dual functions, as can be seen in Figure 15:
CODE[7:0] CCS COE CWE CBUSY ZR36060 ACK CS WR RD DATA[7:0] ADDR[1:0]
CODE[7:0] Code Only CBUSY ZR36060 ACK CS WR RD DATA[7:0] ADDR[1:0] Code ZR36060 CBUSY ACK CS WR RD DATA[7:0] ADDR[1:0] Code (Data Bus Extension)
Host Only
Code/Host Shared
Code/Host Shared
a) Code Master Mode, 8-Bit Code Bus
b) Code Slave Mode, 8-Bit Code Bus
c) Code Slave Mode, 16-Bit Code Bus
Figure 15. The Various Code Interface Modes and the Host Interface
14
Integrated JPEG CODEC
The ADDR[1:0] address pins map 4 direct access registers (Figure 16 and Figure 17):
DATA[7:0]
section 5.0 "Code Interface" for more details). (But CBUSY is only used by the host in Code Slave mode and must be ignored in all other host accesses.) For a complete description of the internal memory register mapping, please refer to section 8.0 "Register and Memory Description".
Read Operation
7 00 01 10 11
0 W W R/W
ADDR[1:0]
MSB Host Address LSB Host Data
Host Address (10 Bits)
Figure 16. Address Space of ZR36060 in Code Master Mode
CS RD WR
7 00 01 ADDR[1:0] 10 11
DATA[7:0] CODE FIFO MSB Host Address LSB Host Data
0 R/W W W R/W + Host Address (10 Bits)
7
CODE[7:0]* CODE FIFO
0
ACK DATA[7:0] ADDR[1:0] Host Address 10 11 Host Data
(*) The Code FIFO register can be 8 or 16 bits wide, depending on the Code16 parameter. When in 16-bit Code Slave mode, the CODE[7:0] bus is an extension of the DATA]7:0] bus.
Write Operation CS RD WR ACK DATA[7:0] ADDR[1:0] Host Address 10 11 Host Data
Figure 17. Address Space of ZR36060 in Code Slave Mode To access the ZR36060's internal Code FIFO (in Code Slave mode only), read and write operations are directed to address 00b. For more information on the Code FIFO access, please refer to section 5.0 "Code Interface". To access the ZR36060's internal registers and markers array, the host must first write the 10-bit host address, followed by a read or write to the 8-bit host data register. Note that the host address is not self-incrementing. However, it does not need to be re-written every data access, only if a different register or memory location is to be accessed. The host address of the location to be accessed can be changed by writing the LSB register, the MSB register, or both, as required. The host interface is an asynchronous interface (see Figure 18). Internally, however, all the interface I/O is synchronized to an internal clock (at twice the VCLKx2 frequency), so VCLKx2 must exist and be stable before any host access can take place. A Host-ZR36060 handshake is performed using the WR or RD strobe pulses, and the ACK signal. Some time after WR or RD goes low, ACK is activated by the ZR36060 to acknowledge that it is ready to input or output host or code data. Only after this event, the host is allowed to release the strobe. The ZR36060 acknowledges the end of access by releasing the ACK signal. A slow host may extend the strobe pulse beyond the activation of the ACK signal by the ZR36060. In a read cycle, data from the ZR36060 stays on the bus until after the RD signal is deasserted. In a write cycle, the data is strobed in on the rising edge of WR. Note that, if it is guaranteed that the minimum WR or RD strobe width is always larger than the minimum specified in the AC Characteristics, the ACK signal can be ignored. When accessing the Code FIFO (address 00b) in Code Slave mode, the ACK signal reflects also the CBUSY status (see
Figure 18. Asynchronous Operation of the Host Interface
4.1 Interrupt Request and Associated Registers
The ZR36060 is capable of requesting an interrupt from the host controller through its JIRQ output signal. This section describes the protocol and registers involved the interrupt request. An interrupt request can occur due to one or more of the following events: * Assertion of the DATERR output (a data corruption event). * Assertion of the END output. * Assertion of the EOI (end-of-image marker detection) output during decompression. * End of the active rectangle of the video field (EOAV) which is being processed by the ZR36060. Each one of the events has a dedicated bit (DATERR, END, EOI, and EOAV, respectively) in the Interrupt Mask Register that enables or disables it as an interrupt requesting event. Each of the events also has a status bit in the Interrupt Status Register. The DATERR bit, and the END bit exactly reflect the level of the DATERR and END output pins, respectively, but with positive logic (as opposed to the negative logic of the output pins).
15
Integrated JPEG CODEC
The EOI bit should only be used when decompressing in Code Slave mode; in Code Master mode it is meaningless. It exactly reflects the level of the EOI signal (with a positive logic). The EOAV bit indicates that the last line of the active area (as defined by the active area parameters), has been sampled (or displayed) by the ZR36060. Note that in Auto Two-Pass Compression mode, the EOAV bit is asserted only in the first pass. The DATERR, END, EOI, and EOAV Interrupt Status bits are set when the respective event occurs, and cleared together with their respective pins (excepting EOAV) at the beginning of the next process, i.e.- at the next START. Note that Interrupt Status Register bits always reflect valid status information regardless of their corresponding interrupts are enabled in the Interrupt Mask Register. When an interrupt-enabled event occurs, the JIRQ output is asserted, and once the ZR36060 asserts END (completion of the field process, i.e. compression or decompression of the current field) it moves to the WAIT-ISR state (see the bubble diagram in Figure 28). JIRQ remains asserted until the host reads the Interrupt Status Register (see Figure 19). When this happens JIRQ is deasserted and the ZR36060 returns to its IDLE state, where it can sample START for the next field process. The Interrupt Status Request register includes another pair of bits, ProCount1:0, that are not related to interrupt requests, but located in this register for convenience. ProCount1:0 is the output of a modulo-4 cyclic counter that advances with every start of a process (every rising edge of END). It is never reset, except by RESET which initializes the counter to 01b. It may be used by host controllers as an indication of a field dropped by the ZR36060 (e.g., when the ZR36060 outputs END of one field after the next one already started). ProCount1:0 are read-only bits.
CS RD WR ACK DATA[7:0] ADDR[1:0] JIRQ
STATUS Address STATUS Data
10
11
Figure 19. Interrupt Acknowledgment by Reading the Interrupt Status Register
5.0 CODE INTERFACE
The code interface has two modes of operation: * Code Master mode * Code Slave mode After RESET the ZR36060 defaults to Code Master mode. The maximum throughput in Master mode is 30 MByte/sec; in 16-bit Slave mode 16.7 MByte/sec; and in 8-bit Slave mode 8.3 MByte/ sec. The master mode is almost identical to the master mode of the ZR36050. It is compatible with the ZR36057 PCI JPEG controller and with the ZR36055 ISA JPEG controller. The slave mode is compatible with common microprocessors or microcontrollers. The operating mode of the code port is selected through the CodeMstr register bit (1b for Code Master mode, 0b for Code Slave mode). * The CAEN signal of the ZR36050 does not exist in the ZR36060. A Master Mode cycle starts with the activation of CCS, on the rising edge of VCLKx2. CCS remains active throughout the bus cycle and remains active continuously in back-to-back cycles. In a read cycle, executed during decompression, COE goes active 0.5 VCLKx2 period after the beginning of the cycle and remains active until the end of the cycle. Data is strobed in on the trailing edge of COE. Similarly, in a write cycle, executed during compression, CWE goes active 0.5 VCLKx2 period after the beginning of the cycle and remains active until the end of the cycle. Examples are shown in Figure 20 and Figure 21. CBUSY is sampled one VCLKx2 before the beginning of each bus cycle and if active, inhibits the bus cycle. If a bus cycle started at the same time CBUSY was sampled active it completes normally. Note: the CBUSY and EOI status bits are not valid in Code Master mode.
5.1 Master Mode
In this mode the compressed data is transferred on the 8-bit CODE[7:0] bus, using the CCS, COE, and CWE outputs to inform the system when a valid code transfer takes place, and CBUSY input to stall further accesses until the system is available again. Master mode differs from the ZR36050's master mode in two minor ways: * The CFIS parameter, that determines the transfer cycle time in this mode, is limited to the values 0b (one VCLKx2 per transfer cycle) and 1b (2 VCLKx2 per transfer cycle)
16
Integrated JPEG CODEC
* 16-bit width (Code16 = 1). CODE[7:0] is an extension of DATA[7:0] to transfer 16-bit words. The byte ordering can be exchanged using the Endian parameter. Code Slave mode accesses are asynchronous (Figure 22). The CS (Code Chip-Select) and ADDR[1:0] inputs can be deasserted after every RD or WR cycle, or, in order to achieve the best performance, left asserted for a burst of code transfer cycles. The host must select one of three different methods to handshake with the ZR36060 throughout the compression/ decompression process:
Code Write (Compression) CCS CWE CBUSY CODE[7:0] (output)
1 VCLKx2 CCS COE CBUSY CODE[7:0] (input)
2
3
4
Code Read (Decompression) 5 6 7 8 9 10 11
12
13
14
* use of the CBUSY signal, or * use of the ACK signal, or * by polling the CFIFO level bits. CBUSY is used as an indication of the empty/full status of the internal code FIFO of the ZR36060. When CBUSY is active (low), it means that the code FIFO is empty (during compression) or full (during decompression). When the host uses this signal, it must sample CBUSY prior to each code access, and hold off the assertion of RD or WR until CBUSY is deasserted. The ZR36060's ACK signal indicates permission to a complete the current cycle. Assertion of ACK indicates that the internal code FIFO is not empty (during compression) or not full (during
Code Read (Compression) CS ADDR[1:0] RD ACK 00 00 00
Cannot perform a new strobe
Figure 20. Master Mode Operation of the Code Bus, with CFIS=0b (1 VCLKx2 Per Transfer)
1 VCLKx2 CCS COE CBUSY CODE[7:0] (input)
2
3
4
Code Read (Decompression) 5 6 7 8 9 10 11
12
13
14
Code Write (Compression) CCS CWE CBUSY
CBUSY DATA[7:0] (CODE[7:0])
CFIFO Empty (Stall Access)
Code Write (Decompression) CS
CODE[7:0] (output)
ADDR[1:0] WR ACK CBUSY DATA[7:0] (CODE[7:0])
00
00
00
Strobe is held low
Figure 21. Master Mode Operation of the Code Bus, with CFIS=1b (2 VCLKx2 Per Transfer)
5.2 Slave Mode
In Slave mode, access to the internal code FIFO is accomplished using the host interface, by reading or writing (depending on compression or decompression mode respectively) to direct access address zero (ADDR[1:0]=00b). The data bus width can be 8 or 16 bits, depending on the Code16 parameter: * 8-bit width (Code16 = 0). Only DATA[7:0] is used for the code transfer.
CFIFO Empty (Stall Access)
Notes: 1. CS can be pulsed, or maintained active for burst of read or write pulses. 2. ACK is not granted when CBUSY is active, in both compression and decompression. 3. The top example (compression) shows a system using CBUSY to decide when to perform the next RD strobe. 4. The bottom example (decompression) shows a system using ACK grant to decide when to terminate the current strobe. Note the extension of the WR cycle when the FIFO is full.
Figure 22. Slave Mode Operation of the Code Bus
17
Integrated JPEG CODEC
decompression), and therefore the transfer can be successfully completed. A host using this signal must not terminate the RD or WR strobe before the ZR36060 acknowledges the cycle by asserting ACK. This can actually stall the host in the middle of a compressed data stream, or between compressed data fields in the case of continuous operation, if the host attempts to read (or write) the FIFO while it is completely empty (or full). The system must be designed to use CBUSY or ACK output signal as a handshake, but not both. Maximum code transfer rate performance is achieved when using CBUSY handshake and 16-bit code bus width. The host also has access to a status register to interrogate the full/empty status of the internal code FIFO via the CBUSY bit (positive logic as opposed to the CBUSY pin state), and to a pair of read-only bits, CFIFO[1:0], which indicate the fullness of the code FIFO as follows: * CFIFO[1:0] == 00b: less than 1/4 of the FIFO is occupied. * CFIFO[1:0] == 01b: less than 1/2 but more than (or exactly) 1/4 of the FIFO is occupied. * CFIFO[1:0] == 10b: less than 3/4 but more than (or exactly) 1/2 of the FIFO is occupied. * CFIFO[1:0] == 11b: more than (or exactly) 3/4 of the FIFO is occupied. Using this register, the host can work in a polling method (instead of using the CBUSY or ACK signals), to determine when it should momentarily stop the code transfer. However, the system must guarantee minimum RD and WR strobe widths as specified in the AC Characteristics. The CFIFO[1:0] status bits are not valid after the EOI (end of code stream) signal and status bit has been asserted. After the last code word is input (in decompression) or output (in compression), the ZR36060 asserts the EOI signal, indicating the end of the code stream with the End-Of-Image marker.
5.2.1 Host abort of a code read or write cycle
During the compression or decompression process the host must obey the handshake rules to create a valid code file. The host, however, can safely abort (e.g.- due to a timeout) a RD or WR cycle only after the EOI signal is asserted. If a code transfer cycle is aborted by the host in the midst of a compression or decompression process, the behavior of the ZR36060 will be unpredictable, and the ZR36060 must be reset to resume normal operation. Figure 23 shows an example of a code transfer abort after EOI is asserted.
5.2.2 Data alignment in Code Slave mode
In compression, in code slave mode, the ZR36060 always completes the compressed data file for each field so that it is 32-bit (double-word) aligned. This is true for both 8-bit and 16-bit interface modes. A variable number of padding bytes of value 0xFF are appended by the ZR36060 after the EOI marker, to complete the last double word. In decompression, such padding bytes
1 CS ADDR[1:0] RD WR ACK CBUSY EOI DATA[7:0] CODE[7:0]
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
11 1 2
00
11 4 3 5
00
11 6
00
7 No ACK = Ignored
CFIFO Full
Data Out
Code In
Code In
Data Out
Try Code In... FAIL!
Data Out
Code In
This example shows status register reads interleaved with code FIFO write transactions. After the end-of-image code, instead of waiting too long (for the ACK signal) until the next field, the host can decide to abort the cycle.
Notes:
1. The host reads the status register, receives ACK normally. 2, 3. The host writes some code bytes (not necessarily two), and the ZR36060 asserts ACK normally. After the second code write cycle, the ZR36060 senses the end-of-image code indicating the last code byte of the current field and asserts CBUSY . 4. In this example the host reads a status register, and ACK is granted, independently of CBUSY state. 5. This is an access to the code FIFO while CBUSY is asserted. No ACK can be issued by the ZR36060, until after the beginning of the next field. The host is stalled for a while, then decides to abort the cycle, i.e.- release the WR strobe without ACK form the ZR36060. The ZR36060 senses this situation as an abort of the cycle and ignores the strobe. Again note, that this is only allowed while EOI is asserted, and not in the middle of the process. 6. The host now decides to read a status register. This operation is completed normally. 7. The host writes code into the ZR36060. The ZR36060 has already started decompressing a new field, so CBUSY and EOI are released and ACK can be issued.
Figure 23. Example of ZR36060 Interleaved Code/Data Accesses and Abort of Access
18
Integrated JPEG CODEC
constitute a legal preamble for the SOI marker code of the next field, and thus are ignored by the ZR36060. In 8-bit interface mode, the number of appended bytes can be 1, 2, 3 or 4. In 16-bit interface mode, the number of appended bytes can be 2, 3, 4 or 5. Note that in both cases, if the number of bytes from the first byte of SOI up to and including the second byte of EOI is an exact multiple of 4, the ZR36060 actually appends 4 more bytes. Note also that in 16-bit mode, if one byte is required to make the total a multiple of 4, the ZR36060 actually appends 5 bytes. consecutive fields showing the behavior of the EOI, END and CBUSY signals. CBUSY is asserted after the last padding byte has been read out. It remains asserted continuously until the first code byte of the next field is available. A code read is shown in the figures while CBUSY is asserted, with the host access stalled. EOI is asserted as soon as the read cycle of last byte of the EOI marker code (0xD9) is completed. END is asserted only after the all the compressed data, including the padding bytes, was read out, and the post-compression calculations are completed and their results stored in the hostaccessible registers. At this time the ZR36060 returns to the IDLE state. Compression of the next field is started when the ZR36060 senses the START signal active.
5.2.3 Transition between fields in compression
For compression, Figure 24 shows code transfer with 8-bit interface and Figure 25 with 16-bit interface, at the transition between
CS ADDR[1:0] RD ACK CBUSY EOI END End-Of-Image marker DATA[7:0] D9 FF FF FF FF
End of Field Process Start new field process due to START
00
00
Start-Of-Image marker D8
FF
32-Bit Alignment (Worst Case Padding) CODE for Field N CODE for Field N+1
Figure 24. 8-Bit Code Slave Mode Compression, Transistion Between Consecutive Fields
CS ADDR[1:0] RD ACK CBUSY EOI END End-Of-Image marker DATA[7:0] CODE[7:0] XXXX XXFF D9FF FFFF FFFF
End of Field Process Start new field process due to START
00
00
FFD8 Start-Of-Image marker
FFXX
32-Bit Alignment (Worst Case Padding) CODE for Field N
CODE for Field N+1
Figure 25. 16-Bit Code Slave Mode Compression, Transistion Between Consecutive Fields
19
Integrated JPEG CODEC
5.2.4 Transition between fields in decompression
For decompression, Figure 26 shows code transfer with 8-bit interface and Figure 27 with 16-bit interface, at the transition between consecutive fields showing the behavior of the EOI, END and CBUSY signals. JPEG compressed files input to the ZR36060 can be any size, not required to be 32-bit, (double-word) aligned. The ZR36060 detects the EOI marker (0xFFD9), asserting EOI and CBUSY at the next write strobe. Note that the host is allowed to write one additional byte after the EOI marker code in 8-bit mode, or one additional word after the word containing the second byte of the EOI marker code 16-bit interface mode. This byte or word is discarded by the ZR36060. If this discarded code byte or word contained one or both bytes of the SOI marker of the next field, the ZR36060 automatically reconstructs the marker when it starts decompressing the next field. Note that EOI and CBUSY may remain unasserted until END is asserted, if the host has other means to detect the EOI marker code and therefore does not issue the additional write strobe. Attempts to access the code FIFO while CBUSY is asserted will be held off until the FIFO is available again, using the ACK signal. In this example, a WR pulse is shown being extended until the next field begins, when CBUSY is deasserted. END is asserted only after the whole decompressed field has been output from the video interface. At this time the ZR36060 sets the EOAV status bit and returns to the IDLE state. Decompression is started again when the ZR36060 senses the START signal active.
CS ADDR[1:0] WR ACK CBUSY EOI END DATA[7:0] XX XX FF End-Of-Image marker CODE for Field N D9 XX
End of Field Process Start new field process due to START
00
00
FF Start-Of-Image marker
D8
CODE for Field N+1
Figure 26. 8-Bit Code Slave Mode Decompression, Transistion Between Consecutive Fields
CS ADDR[1:0] WR ACK CBUSY EOI END DATA[7:0] CODE[7:0] XXXX XXFF D9FF End-Of-Image marker CODE for Field N FFFF FFFF
End of Field Process Start new field process due to START
00
00
FFD8 Start-Of-Image marker
FFXX
CODE for Field N+1
Figure 27. 16-Bit Code Slave Mode Decompression, Transistion Between Consecutive Fields
20
Integrated JPEG CODEC
6.0 OPERATION
6.1 ZR36060 Functional States
For the purposes of this description, the ZR36060 can be viewed as having 7 states: * RESET - In this state the RESET input is held active. * SLEEP - Power-down. The SLEEP input is held active in this state. * IDLE - END is asserted and the ZR36060 is waiting for START. * WAIT-ACTIVE - After the ZR36060 sensed START asserted, it waits for the beginning of the active area of the next field to be processed (this depends on the state of FRAME when START was sampled active). END is deasserted. * CMP - Compression of the active area. The video bus is input, and the code data bus is output. END is deasserted. * EXP - Decompression (expansion) of the active area. The video bus is output, and the code data bus is input. END is deasserted. * WAIT-ISR - After the ZR36060 finished the compression or decompression and asserted END while JIRQ is active (due to a non-masked interrupt), the ZR36060 waits in this state for the host to read the Interrupt Status Register.
active area[1] & compression ! START
Power-Up
RESET
RESET
SLEEP &! RESET
! SLEEP & ! RESET SLEEP ! SLEEP SLEEP
IDLE
SLEEP
START END & ! JIRQ ! (active area) END & ! JIRQ
WAIT ACTIVE
active area[1] & decompression
CMP
EXP
END & JIRQ
END & JIRQ JIRQ
6.2 State Transitions
Figure 28 depicts the states and their transitions.
! JIRQ
WAIT ISR
6.3 The SLEEP State
In this state, all the pins remain in the logic states they were in immediately before the transition to SLEEP. No host, video or code interface operation is allowed in the SLEEP state. When the ZR36060 leaves the SLEEP state it returns to IDLE, ready for the next compression or decompression operation. This state is also used internally to lock the internal PLL to the frequency of VCLKx2, so it is mandatory to go through the SLEEP state at least once after power-up and before operating the device (see section 7.0 "Power Management and Powerup").
1. Active area of the correct field, depending on the state of FRAME when START was sampled active.
Figure 28. ZR36060 Functional States internal memory (see chapter 8.0 "Register and Memory Description" for details). Then, the host sets the ZR36060's (write-only) Load bit. This commands the ZR36060 to initialize or `Load' all internal hardware blocks with the parameters in its internal memory, and also to decode and expand the abbreviated format Huffman and Quantization tables. While the ZR36060 is performing this Load operation, the (read-only) Busy bit is set to `1'. The host must poll for the completion of the loading, i.e.- wait for the Busy bit to be reset to `0', before starting the compression or decompression process. The START signal is ignored during the execution of the Load, i.e.- the ZR36060 remains in the IDLE state (with END asserted). Only after Load is completed (Busy is reset) and the new parameter values become effective, the ZR36060 is ready to sample START again to move to the WAIT-ACTIVE state to start the compression/decompression process (see Figure 29). Parameters and status registers can be read in any ZR36060 state (besides RESET and SLEEP).
6.4 Loading Parameters and Tables
Prior to a compression or decompression process the host must load the appropriate parameters and tables into the ZR36060. The parameters affect the compression/decompression mode, the video interface, and the operation of the code port. All parameters and tables may be loaded only when the ZR36060 is in the IDLE state. First, the host controller writes (via the host interface) the desired parameters and/or tables in their correct location in the 1Kbyte
21
Integrated JPEG CODEC
System decides to compress the next field (pulls START low). START (async) FRAME (async) END state IDLE WAIT ACTIVE RTBSY CBUSY CCS Video Bus Tb System senses END deasserted, so deasserts START to compress next field only, then stop.
using the PVALID input. This may be useful, for example, when compressing still pictures.
Strip Memory
JPEG Codec
CODE FIFO CODE Bus
Tb = Delay while the ZR36060 completes execution of the Load command.
Figure 30. Data Flow in Compression, Code Master When the code interface operates in slave mode (see Figure 31) the scenario is almost identical. The main difference is that CBUSY is now an output of the ZR36060, and it is used to indicate that the code FIFO is "nearly empty", thus the host must stop reading out the code until CBUSY indicates that the FIFO occupancy is above its threshold.
Figure 29. IDLE to WAIT-ACTIVE state transistion
6.5 Data Flow Overview
This section provides an overview of the data flow in the ZR36060 during compression and decompression. For this purpose it is useful to view the ZR36060 (see Figure 30 through Figure 33) roughly as a JPEG engine with one dual port data buffer on each side: the code FIFO buffer on one side and the video buffer (strip buffer) on the other side.
Strip Memory Video Bus
JPEG Codec
CODE FIFO CODE Bus
6.5.1 Data Flow in Compression
The video input, after being processed in the video interface, is written to the strip buffer in raster format. The JPEG engine reads out the data in block format, and writes the JPEG code into the code FIFO on the other side. From the FIFO the data is transferred out either by the ZR36060 itself, if it is the code bus master, or by the host controller, if the ZR36060 is in code slave mode. When the ZR36060 is the code bus master (see Figure 30) it writes out the code as long as its CBUSY input is not asserted. When the code FIFO is empty the ZR36060 does not perform code write cycles. If the host controller is too slow and it asserts CBUSY for too long, the code FIFO might fill up. In order to prevent overflow, the ZR36060 stops reading data from the Strip buffer. If this situation continues long enough, the Strip buffer overflows, because video keeps flowing in. A Strip buffer overflow is a data corruption event. At the system level this event may be prevented by two means: First, the host should be able to accept the code at the same rate it is generated by the ZR36060. Second, some system configurations may have the capability to halt the video input stream when the Strip buffer is close to overflow (16 pixels, or less, from overflow). The ZR36060 indicates this "nearly full" condition with its RTBSY output. One configuration for implementing this is if the ZR36060 is the master of the video syncs, and the system stops the video
RTBSY
CBUSY CCS
Figure 31. Data Flow in Compression, Code Master
6.5.2 Data Flow in Decompression
The JPEG code is transferred on the code bus into the code FIFO, either by the ZR36060, in Code Master mode, or by the host, in Code Slave mode. The JPEG codec engine writes the decoded video into the Strip buffer in block format. The video interface reads the video out in raster format, executes the postprocessing operations and outputs the video on the digital video bus. When the ZR36060 is the code bus master (see Figure 32) it reads in the code as long as its CBUSY input is not asserted. Whenever the code FIFO is full the ZR36060 stops reading code in. If the host controller is too slow and it asserts CBUSY for too long, the code FIFO may become empty. In order to prevent underflow the ZR36060 stops writing data into the Strip buffer. If this situation continues long enough, the strip buffer underflows, because the video unit keeps reading out video from the Strip buffer, in order to keep up with the timing of the digital video bus. A Strip buffer underflow is a data corruption event. At the system level this event may be prevented by two means: First, the system should be able to provide the code at the rate it is required by the ZR36060. Second, some system configurations may have the capability to stop the video output stream when the Strip buffer is close to underflow (16 pixels, or less, away from underflow). The ZR36060 indicates this "nearly empty" condition with its RTBSY output. One configuration for implementing this is if the ZR36060 is the master of the video syncs, and the
22
Integrated JPEG CODEC
system stops the video using the PVALID input. This may be useful, for example, when decompressing still pictures.
2 Processed Fields VSYNC Strip Memory Video Bus JPEG Codec CODE FIFO CODE Bus START FRAME RTBSY CBUSY CCS END state IDLE WAIT ACTIVE CMP IDLE WAIT ACTIVE CMP IDLE EVEN ODD EVEN ODD
Figure 32. Data Flow in Decompression, Code Master When the code interface operates in slave mode (see Figure 33) the scenario is almost identical. The main difference is that CBUSY is now an output of the ZR36060, and it is used to indicate that the code FIFO is "nearly full", thus the host must momentarily stop writing code until CBUSY indicates that the FIFO occupancy is below its threshold.
Figure 34. Compression with START and FRAME continuously asserted If FRAME is not active when START is sampled (Figure 35), the ZR36060 always starts compressing the next field (i.e., at the next VSYNC).
3 Processed Fields
Strip Memory Video Bus
JPEG Codec
CODE FIFO CODE Bus VSYNC START
RTBSY
CBUSY
WR FRAME END
Figure 33. Data Flow in Decompression, Code Slave
IDLE
WAIT
IDLE
IDLE
The ZR36060 has one decompression mode (called simply decompression), and four compression modes: * Compression Pass * Statistical Compression Pass * Auto Two-Pass Compression * Tables-Only Compression Pass The following sections describe these modes.
WAIT ACTIVE
CMP
CMP
WAIT
6.6 Compression and Decompression Modes
state CMP IDLE
Figure 35. Compression with continuous START asserted and FRAME Deasserted The VSYNC edge used by the ZR36060 to make the decision on the `next' field is configurable with the FIVedge parameter (leading or trailing edge). During IDLE, CBUSY (if it is configured as output, in code slave mode) is active, preventing the host controller from reading code, since the code FIFO buffer is empty. Once the compression process starts CBUSY is released and the host controller is expected to read the code. If the ZR36060 is the master of the code bus it drives out the code only after the compression process starts (the active area begins). When the compression of the field is not stopped because of an interrupt request targeted to the host (JIRQ assertion), then upon completion the ZR36060 asserts the END signal and returns to the IDLE state, looking again at START and FRAME. Note that it does not matter if the host controller continuously asserts START (and/or FRAME) or if it only asserts START (and/or FRAME) after the ZR36060 asserts END. The reason is that the ZR36060 interrogates START only when it is in the IDLE state. See Figure 36.
6.7 Compression Pass
When the ZR36060 is in the IDLE state, and after the correct initialization has been done by the host (loading parameters and/or tables), it waits for a command (assertion of START) to start compressing. RTBSY is not asserted at this time. Once the ZR36060 senses an active (low) START, it checks the level of FRAME, and then, if FRAME is active (Figure 34), the ZR36060 starts compressing the next odd field (i.e., at the next odd VSYNC). Note: If FRAME is maintained active, and consequently it will be detected active every time START is sampled active, the ZR36060 will compress only the odd fields. This is a convenient method for implementing field decimation.
23
Integrated JPEG CODEC
ZR36060 samples START again, and if START is asserted a new process begins.
2 Processed Fields
Host decide to compress next field only VSYNC START FRAME END state IDLE WAIT ACTIVE CMP
2) If DATERR is enabled as an interrupt requesting event, JIRQ is asserted together with the assertion of the DATERR output, and when the ZR36060 completes the current process it enters the WAIT-ISR state and remains "frozen" (ignoring START) until the host reads the Interrupt Status register. At this time the ZR36060 goes back to its IDLE state and is again ready to start a new process, depending on START.
IDLE
IDLE
WAIT CMP ACTIVE
In both cases, DATERR is deasserted at the beginning of the next process, i.e. simultaneously with the deassertion of END. In compression the ZR36060 identifies a data corruption condition if: a) the strip buffer overflows, or b) VSYNC (leading or trailing edge controlled by the FIVedge parameter) of the next video field arrives before END of the current field is asserted.
Figure 36. Compression with Pulsed START The compression pass is always executed with Bit Rate Control (BRC). At the end of every compression process the ZR36060 calculates the new scale factor, and, if the FSF (Fixed Scale Factor) bit equals zero, it writes the new scale factor in the Scale Factor register. It uses this new value in the register as the scale factor for compressing the next image field. The host only has to program the initial scale factor to be used for compressing the first field. Otherwise, if FSF=1, the ZR36060 uses a fixed scale factor for all incoming fields. In a compression pass the ZR36060 does not update the Allocation Factor (AF). During encoding of each block the ZR36060 calculates a measure of the spatial "activity" in this block, denoted BACT. If the Block Accumulated Code Volume (BACV) exceeds the specified allocation (given by BACT*AF), or if it exceeds the Maximum Block Code Volume (MBCV), the code for the block is truncated accordingly. Note that both means of bit rate controlling (namely truncation due to the Allocation Factor, or truncation due to the MBCV) cannot be set "off" directly, but they can be practically eliminated by setting MBCV and/or AF to their maximum values. Note: Use of the Allocation Factor is only valid if the compression pass follows a Statistical Pass. If only Compression Passes are executed, the mode normally used for motion JPEG compression, the Allocation Factor must be set to its maximum value to avoid corruption of the image.
6.8 Statistical Compression Pass
In this mode the ZR36060 goes through all the calculations involved in encoding the given video, but without writing any code to the code FIFO. That is, the ZR36060 does not assert CCS, COE, CWE as a code master, or CBUSY as a code slave. At the end of the process the ZR36060 writes the new scale factor into the SF register, and the calculated AF, ACV, and ACT values into their respective registers. Then it asserts the END signal and returns to the IDLE state.
6.9 Auto Two-Pass Compression
In this mode the ZR36060 first executes a Statistical Compression Pass, then, without asserting END, it immediately starts a Compression Pass. Activation of START (and FRAME if needed) is required only for the first pass. The second pass follows immediately with the next VSYNC, without regard for START and FRAME. (Note that START and FRAME are only sampled when the ZR36060 is in IDLE, and in this mode the ZR36060 does not go into IDLE between the two passes).
6.7.1 Data Corruption during Compression
If during the compression of a field the ZR36060 senses a data corruption event, it immediately asserts the DATERR output. However, the ZR36060 continues the process until it finishes compressing the field. At this time it asserts END and enters its IDLE state. 1) If DATERR is not enabled as an interrupt requesting event (i.e., it is cleared in the Interrupt Mask register), then the
6.10 Tables-Only Compression Pass
In this mode the ZR36060 produces only the abbreviated format for table specification, that is, its code output contains no frame, scan, or Huffman-coded segments. The output code includes the SOI marker, table marker segment(s), optional APP and/or COM marker segments, and the EOI marker. The process is activated by START (possibly with FRAME), and upon completion END is asserted and the ZR36060 returns to IDLE.
24
Integrated JPEG CODEC
1 ODD 2 EVEN 3 ODD 4 EVEN 5 ODD 6 EVEN 7 ODD 8 EVEN 9 ODD 10 EVEN 11 ODD 12 EVEN
VSYNC _active _state
IDLE
WaitACT
CMP
i
CMP
i
i = go through IDLE & WAITACT)
CMP (w/error)
WaitISR i
CMP
i
CMP (w/error)
i
CMP
i
CMP
IDLE
START FRAME RTBSY DATERR CSS (code master) CBUSY (code slave) DATA Bus (CODE bus) END JIRQ Notes: 1. In field #1, START & FRAME asserted indicate to begin on next ODD VSYNC 2. Wait for next ODD field; meanwhile START signal is ignored (END not asserted) 3. Field #3 is compressed, active area only, issue END and return to IDLE. At this point, START is sensed low (w/o FRAME) -> start cmp. next VSYNC (next field). 4. Field #4 is compressed on active area. Again, after END system assert START w/o FRAME, so next field must be compressed too. 5. Begin field compression, but system is too slow to take data out to system memory, so DATERR is asserted. Sampling of END and DATERR inform the system of an illegal field. Since interrupt request on data error is enabled, ZR36060 assert JIRQ and wait until the host acknowledge the JIRQ by reading the associated interrupt status register. 6. During this field, the host service the interrupt (ZR36060 de-assert JIRQ) and assert again START (w/o FRAME) for next field compression. In this example, the host also disables interrupts after servicing this one. 7. Field #7 is compressed. After END system assert START for next field compression. 8, 9. Field is compressed normally, but during the last lines of active area, the system response is slow and the last part of the code is fetched at a much slower pace. Next field #9 begins (VSYNC assertion) without issuing END by the ZR36060. This is an illegal condition indicated by DATERR. No JIRQ here since interrupts are disabled. START is sensed low for next field compression (ZR36060 skips field #9). 10, 11. Fields are compressed normally. START is de-asserted during field #11, therefore after END assertion the ZR36060 returns to IDLE and wait for next operation. 3 4 5 7 8 10 11
Figure 37. Examples of ZR36060 Compression (After Host Loaded Parameters & Load Command)
6.11 Decompression
Before decompression the ZR36060 is in the IDLE state. After the correct initialization has been done by the host (loading of parameters and/or tables), the ZR36060 is ready to receive a command to start decompression. The video bus already outputs the background color, and if the ZR36060 is a code slave, CBUSY is asserted, so the host cannot write compressed data to the ZR36060. The host is now expected to send the start command. The ZR36060 will then start reading compressed data (if it is the code bus master), decoding it, and filling up the strip buffer with pixels. However, pixels will not start flowing out the video bus before the VSYNC that follows START (or the odd VSYNC, if FRAME was asserted together with START). Host controllers that are capable of synchronizing the start command to VSYNC may do so, providing the start command as soon as possible after a VSYNC. This makes sure that once VSYNC arrives, the ZR36060 has enough pixels in the strip buffer to avoid a condition of strip buffer underflow. In systems where the video sync signals can be controlled by the host, this
capability can be used to guarantee that START is asserted long before the next VSYNC. Once the host controller has sent the start command (by asserting the START signal) CBUSY is deasserted (if it is configured as output, i.e., in code slave mode), and the RTBSY output is asserted indicating that the strip memory is initially (close to) empty (underflow). The host should now provide compressed data to the ZR36060 as quickly as possible, and fill the strip memory. Deassertion of RTBSY is an indication that sufficient data is available in the strip buffer to start video output. Every time that the ZR36060 senses that the strip buffer is close to an overflow (full), it asserts an internal flag that stops the transfer of pixels into the strip buffer, and eventually might result in assertion of CBUSY (in code slave mode) or in stopping of compressed data acquisition (in code master mode). When the ZR36060 senses the EOI marker, or when the active portion of the video field is over (whichever occurs later), it asserts the END signal and returns to the IDLE state, waiting for a new start command. (As in compression, the host controller may choose to leave START asserted continuously, rather than asserting it after every END).
25
Integrated JPEG CODEC
6.11.1 Data Corruption during Decompression
If during the decompression of a field the ZR36060 senses a data corruption event, it immediately asserts DATERR, then continues the decompression process until it senses the EOI (End Of Image) marker or the end of the active video area (whichever occurs later). At this time it asserts END and enters the IDLE state. The deassertion of END (upon START for the next field) deasserts the DATERR signal. 1) If DATERR is not enabled as an interrupt requesting event (i.e., it is cleared in the Interrupt Mask register), then the ZR36060 samples START again, and if START is asserted a new process begins. 2) If DATERR is enabled as an interrupt requesting event, JIRQ is asserted together with the assertion of DATERR, and when the ZR36060 completes the current process it enters the WAITISR state and remains "frozen" (without regard for START) until the host reads the Interrupt Status register. At this time the ZR36060 goes back to IDLE and is again ready to start a new process, waiting for START. In decompression the ZR36060 identifies a data corruption condition if the strip buffer underflows, i.e.- insufficient blocks of decompressed data to start outputting the first video line of a strip when required.
VSYNC _active _state
1 ODD
2 EVEN
3 ODD
4 EVEN
5 ODD
6 EVEN
7 ODD
8 EVEN
9 ODD
10 EVEN
11 ODD
12 EVEN
IDLE
WaitACT
EXP
i
EXP
i
i = go through IDLE & WAITACT)
EXP (w/error)
WaitISR i
EXP
i
EXP (w/error)
i
EXP
i
EXP
IDLE
START FRAME RTBSY DATERR CSS (code master) CBUSY (code slave) DATA Bus (CODE bus) END JIRQ Notes: 1, 2. In field #1, START & FRAME asserted indicate to decompress on next ODD VSYNC (field #3). Code can be input immediately after START assertion (filling CFIFO), to decode and fill with 8 lines of video the 1st. strip buffer before active video time arrive. After the 1st. strip is completed, code is no longer fetched, and the ZR36060 waits for the active area of the next ODD field. 3. Field #3 decompression continues and complete, issue END and return to IDLE. RTBSY goes low after active area completes indicating strip memory empty. 4. Field #4 is decompressed normally. 5. Begin field decompression, but system is too slow to feed new code data, so DATERR is asserted. Sampling of END and DATERR inform the system of an illegal field. Since interrupt request on data error is enabled, ZR36060 assert JIRQ and wait until the host acknowledge the JIRQ by reading the associated interrupt status register. 6. During this field, the host service the interrupt (ZR36060 de-assert JIRQ) and assert again START (w/o FRAME) for next field compression. In this example, the host also disables interrupts after servicing this one. 7. Field #7 is decompressed. After END , system assert START for next field. 8, 9. In Field #8 start to input code, but somewhere during the active area, the system is busy (without feeding new code) long enough that the ZR36060 issue a DATERR (no JIRQ here since interrupts are disabled). Despite this situation the system continue to feed new code to the ZR36060 until END which occurs only after next field #9 beginning (VSYNC assertion). Now START is sensed low meaning that next decompression will happen on field #10 (skipping field #9). 10, 11. Fields are decompressed normally. START is not asserted during field #11, therefore after END assertion the ZR36060 returns to IDLE and wait for next operation. 3 3 4 5 7 8 8 10 11
Figure 38. Examples of ZR36060 Decompression (After Host Loaded Parameters & Load Command)
26
Integrated JPEG CODEC
7.0 POWER MANAGEMENT AND POWER-UP
The ZR36060 has two power consumption modes: the normal mode, and a low-power mode, called the SLEEP state, achieved by activating the SLEEP pin. This power saving is achieved by disabling the internal clocking to all flip-flops and gates, so this mode can be seen as a frozen state of the ZR36060. All outputs retain their states, and bidirectional signals remain in their last direction status Transitions to or from the SLEEP state must be done via the IDLE state. No host accesses are allowed in the SLEEP state, and during the IDLE - SLEEP transition. Otherwise the ZR36060 must be reset again. After the SLEEP pin is de-activated, the ZR36060 is operational again, without the need for a reset, retaining all registers, markers and parameters previously loaded. Before START can be activated again for the next compression or decompression, the host must write the Load bit. Deactivation of SLEEP also serves to initiate the coarse frequency lock procedure of the internal PLL. It is mandatory to pulse SLEEP after power-up, when the system clock (VCLKx2) is setup and stable (within 10% of its nominal frequency). The coarse lock must be initiated (using the SLEEP pin) each time the system changes the frequency of VCLKx2 frequency, for example if the video standard is changed. See Figure 39. The coarse PLL frequency lock procedure takes 5000 VCLKx2 cycles, and is executed every low-to-high transition of SLEEP. The ZR36060 remains in the SLEEP state during this time interval.
VCC RESET SLEEP _state Power On RESET
(SLEEP must be inactive) (8 VCLKx2 min)
WAIT VCLKx2 INITIALIZED & STABLE
(board config)
SLEEP
LOCK
IDLE
(operational)
RESET Period: Minimum pulse of 8 VCLKx2 cycles. WAIT Period: Depend of system properly initialize the VCLKx2 to correct operating frequency. SLEEP Pulse: Minimum pulse of 8 VCLKx2 cycles. LOCK Period After SLEEP deasserted, system must wait 5,000 VCLKx2 cycles until the ZR36060 is correctly locked to the clock frequency. IDLE: The ZR36060 is ready for operation.
Figure 39. Power-Up Sequence and SLEEP Operation
27
Integrated JPEG CODEC
8.0 REGISTER AND MEMORY DESCRIPTION
The ZR36060 internal memory space is implemented as 1024 bytes of RAM, accessible by the host controller through the host interface. The contents of this RAM may be loaded into the final storage registers and tables using the Load command (refer to 6.4 "Loading Parameters and Tables"). Figure 40 depicts the partitioning of the RAM. A "default" is specified for each register bit. This is its value after reset.
8 Bits Data Host Address Host Data Host Interface 022h 030h Video Registers 052h Spare 060h 1 KB RAM 000h Codec Control Registers Debug (Testing)
Code FIFO Status Register (Read only)
0x001 type default 7 Busy RW 0 6 5 0 X X X X 4 3
Address 0x001
2 1 0 CBUSY CFIFO1 CFIFO0 RW RW RW X X 0
CFIFO[1:0]: Indicates the fullness of the Code FIFO (ready only bits): 00 - less than 1/4 of the Code FIFO is occupied. 01 - less than 1/2 but more than (or exactly) 1/4 is occupied. 10 - less than 3/4 but more than (or exactly) 1/2 is occupied. 11 - more than (or exactly) 3/4 of the Code FIFO is occupied. These bits are valid only when EOI is not asserted. CBUSY: Indicate the full/empty condition of the code FIFO (read only bit - identical to CBUSY pin state, inverse logic) 0 - code FIFO not full / not empty 1 - code FIFO full / empty This bit is valid only when CBUSY is an output; i.e.- in code slave mode. Busy: Status of the Load operation. The internal load of parameters can take ~100 microseconds. The host must poll this bit to know when the ZR36060 is ready (not Busy) to load a new parameter set or start a compression/decompression process. 0 - ZR36060 is ready to operate, no Load operation in progress 1 - Load is in progress now, don't access any internal memory location while this bit is set
JPEG Markers Array
3FFh
Code Interface Register
0x002 type default 7 Code16 RW 0 6 Endian RW X 5 4 0 X 3 2 CFIS RW X
Address 0x002
1 0 - X 0
CodeMstr
Figure 40. Internal Memory Map
X
X
RW 1
8.1 General Control Registers
LOAD Parameters Register
0x000 type default 7 Load RW 0 6 5 4 0 X X X X X X 3 2
CodeMstr: The ZR36060 is the Master or Slave of the Code bus 0 - Code Slave mode 1 - Code Master mode
Address 0x000
1 0 SyncRst RW 0
CFIS: Only in Master mode, defines the number of clocks for each code byte transfer. Must be 0 in Code Slave mode. 0 - one VCLKx2 cycle 1 - two VCLKx2 cycles Endian: Defines the byte ordering when using 16-bit code slave interface. Must be 0 in Master mode or 8-bit Slave mode. 0 - first byte (`FF' of `FFD8' SOI code) is on DATA[7:0] bus 1 - first byte (`FF' of `FFD8' SOI code) is on CODE[7:0] bus Code16: Defines the code bus width for slave mode only. Must be 0 in Master mode. 0 - 8-bit code bus 1 - 16-bit code bus
SyncRst: Resets the video sync generator. 0 - No reset 1 - Reset the syncs. Start horizontal/vertical counting from 0, 0. The Sync Generator is maintained in reset state until the host writes 0 again to this bit. Load: Load all the internal memory parameters (including tables) to the respective ZR36060 internal blocks. After writing Load = 1, the ZR36060 sets the Busy bit until the load is complete and the ZR36060 is ready to operate. The Load bit must be set every time a new parameter is written anywhere in the internal memory. 0 - No effect 1 - Load parameters now
28
Integrated JPEG CODEC
Codec Mode Register
0x003 type default 7 COMP RW 1 6 ATP RW X 5 PASS2 RW X 4 TLM RW X 3 0 - X 2 BRC RW X
Address 0x003
1 FSF RW X 0 0 - X
Interrupt Mask Register
0x007 type default 7 0 - X 6 0 - X 5 0 - X 4 0 - X 3 EOAV RW X 2 EOI RW X
Address 0x007
1 END RW X 0 DATER RW X
All other combinations are illegal 11000100 - Auto Two-Pass Compression 10000100 - Statistical Compression Pass 10100100 - Compression Pass with Variable Scale Factor 10100110 - Compression Pass with Fixed Scale Factor 10110000 - Tables-Only Compression Pass 00000000 - Decompression Pass
DATERR: Enable interrupt upon DATERR signal assertion during the process 0 - Interrupt disabled 1 - Interrupt enabled END: Enable interrupt upon END assertion at the end of process 0 - Interrupt disabled 1 - Interrupt enabled EOI: Enable interrupt when the EOI marker is being read or written (EOI assertion) at the code interface 0 - Interrupt disabled 1 - Interrupt enabled EOAV: Enable interrupt upon End-Of-Active-Video area during the process 0 - Interrupt disabled 1 - Interrupt enabled
Reserved
0x004 type default 7 0 - X 6 0 - X 5 0 - X 4 0 - X 3 0 - X 2 0 - X
Address 0x004
1 0 - X 0 0 - X
Must be 0x00 for correct operation.
Interrupt Status Register (Read Only) Maximum Block Code Volume Register
7 0x005 type default 6 5 4 MBCV RW X 3 2
Address 0x008
3 EOAV R 0 2 EOI R 0 1 END R 1 0
DATERR
Address 0x005
1 0
0x008 type default
7 6 ProCnt1 ProCnt0 R R 0 0
5 X - X
4 X - X
R 0
MBCV7:0: Maximum Block Code Volume. In all compression modes, MBCV limits the maximum number of bits that will be used to encode each 8x8 block of samples. The number of bits is twice the value coded in this register. MBCV=01 represents two bits per block, and MBCV=FF represents 510 bits per block.
DATERR: Status of the DATERR output pin 0 - DATERR is not asserted (normal operation) 1 - DATERR is asserted (data corruption) END: Status of the END output pin 0 - END is not asserted (during the process) 1 - END is asserted (process and returned to IDLE state) EOI: Status of the EOI output pin 0 - an EOI marker event did not occur 1 - an EOI marker has been read or written by the host EOAV: Latch an event upon End-Of-Active-Video area during the process 0 - an EOAV event did not occur (video is still being output or sampled) 1 - an EOAV event occurred (active area of video has finished) ProCnt1:0: 2-bit cyclic Process (compression or decompression) counter. It is reset to one by RESET of the chip and incremented upon START of each field process.
Markers Enable Register
0x006 type default 7 APP RW X 6 COM RW X 5 DRI RW X 4 DOT RW X 3 DHT RW X 2 0 - X
Address 0x006
1 0 - X 0 0 - X
In compression, this register specifies which of the optional marker segments to include in the compressed data. Not used in decompression 0 - don't include the marker segment 1 - include the marker segment APP: Reads the Application segment from the Internal Memory and writes it to the compressed data during the Compression Pass. Used also in Tables-only pass. COM: Reads the Comment segment from the Internal Memory and writes it to the compressed data during the Compression Pass. Used also in Tables-only pass. DRI: Define Restart Interval. Enables the restart mechanism and writes the DRI marker segment to the compressed data during the Compression Pass. When the restart interval is zero, the restart function is disabled. DQT: Define Quantization Tables. Reads the base Quantization Tables defined in the DQT segment in the Internal Memory, multiplies the quantization values by Scale Factor (SF), rounds them to eight bits and writes the results together with the DQT marker and parameters in the compressed data during the Compression Pass or the Tables-Only Pass. The number of Quantization Tables to be processed is inferred from the LEN (segment length) parameter of the DQT segment. Note: the identical scaled tables are used to compress the data. DHT: Define Huffman Tables. Reads the Huffman Tables defined in the DHT segment in the Internal Memory, and writes the DHT segment in the compressed data during the Compression Pass or the Tables-only Pass.
Target Net Code Volume Register
7 0x009 0x00A 0x00B 0x00C type default 6 5 4 3 TCV_NET[31:24] TCV_NET[23:16] TCV_NET[15:8] TCV_NET[7:0] R/W X
Address 0x009 - 0x00C
2 1 0
TCV_NET[31:0]: Target Net Code Volume. Used only in Auto Two-Pass (2nd. pass) and Compression Pass. TCV_NET is used by the ZR36060 to calculate the new Scale Factor (SF) and Allocation Factor (AF) after the Compression Pass. It is the Target Code Volume in bits for the compressed data excluding the marker segments.
29
Integrated JPEG CODEC
Target Data Code Volume Register
7 0x00D 0x00E 0x00F 0x0010 type default 6 5
Address 0x00D - 0x010
2 1 0
Accumulated Total Activity Registers
7 0x01A 0x01B 0x01C 0x01D type default 6 5 4 3 ACT[31:24] ACT[23:16] ACT[15:8] ACT[7:0] R X
Address 0x01A - 0x01D
2 1 0
4 3 TCV_DATA[31:24] TCV_DATA[23:16] TCV_DATA[15:8] TCV_DATA[7:0] R/W X
TCV_DATA[31:0]: Target Data Code Volume. Used only in Auto Two-Pass (1st. pass) and Statistical Pass. TCV_DATA is used by the ZR36060 to calculate the new Scale Factor (SF) and Allocation Factor (AF) after the Statistical Pass. It is the Target Code Volume in bits for the compressed data excluding the marker segments, the EOB (end-of-block) Huffman codes, the byte stuffing, and the bit stuffing (which completes the last data byte). Byte stuffing typically represents about 1% of the code volume.
ACT[31:0]: Accumulated Total Activity of the image, used for ZR36060 internal calculations. ACT is updated at the end of Statistical Pass and Auto two-pass compression modes. It is a 32-bit fixed point binary number.
Accumulated Truncated Bits Registers
7 0x01E 0x01F 0x020 0x021 type default 6 5
Address 0x01E - 0x021
2 1 0
Scale Factor Registers
7 0x011 0x012 type default 6 5
Address 0x011 - 0x012
4 3 2 SF[15:8] (integer part of SF) SF[7:0] (fractional part of SF) R/W X 1 0
4 3 ACV_TRUN[31:24] ACV_TRUN[23:16] ACV_TRUN[15:8] ACV_TRUN[7:0] R X
SF[15:0]: Scale Factor. It is used for scaling the quantization table values. SF should be provided to the ZR36060 as a parameter at the beginning of every compression operation. If Variable SF option is used, this register is internally computed and updated at the end of every compression pass in order to converge to the desired TCV. SF is a 16-bit fixed point binary number, with 8-bits after the binary point.
ACV_TRUN[31:0]: Total number of truncated bits of the frame as a result of block truncation in Compression Pass and Auto Two-Pass modes. ACV_TRUN is updated at the end of these modes. It is a 32-bit fixed point binary number.
8.2 ID and Testing Registers
Identification Registers (Read Only)
7 6 5
Address 0x022 - 0x023
2 1 0
Allocation Factor Registers
7 0x013 0x014 0x015 type default 6 5 4 3 AF[23:16] AF[15:8] AF[7:0] R/W X
Address 0x013 - 0x015
2 1 0
0x022 type default 0x023 type default
0
0
1
4 3 DeviceID R 1 0 Revision R
0
1
1
0
0
0
0
0
0
0
1
DeviceID: Hardwired to the chip device ID number (0x33). AF[23:0]: Allocation Factor. AF is used to compute the Allocated Code Volume for each block. The AF is computed by the ZR36060 and written to the AF register at the end of the Statistical Pass. This value can later be used in a Compression Pass; otherwise for Compression Pass without prior statistics, AF must be programmed to 0xFFFFFF prior to the compression. AF is a 24-bit fixed point binary number, with 19-bits after the binary point. Revision: Hardwired to the current chip revision number (0x01).
Test Control Registers
7 0x024 0x025 type default 6 5 4 0 0 - X 3
Address 0x024 - 0x025
2 1 0
Accumulated Code Volume Registers
7 0x016 0x017 0x018 0x019 type default 6 5 4 3 ACV[31:24] ACV[23:16] ACV[15:8] ACV[7:0] R X
Address 0x016 - 0x019
2 1 0
Reserved: Reserved for test mode. Must be initialized to 0x00 for correct operation.
ACV[31:0]: Accumulated Code Volume. It is a 32-bit fixed point binary number. ACV register is used in 2 ways depending on the compression pass: (1) ACV_DATA: To store the Net Code Volume in bits unit excluding marker segments, EOB codes and bit and byte stuffing at the completion of the Statistical Pass. (2) ACV_NET: To store the Net Code Volume in bits excluding marker segments at the completion of every Compression Pass. ACV_NET / 8 = number of bytes passed through the Code FIFO excluding marker segments. It does not include the padding bytes for double-word alignment.
30
Integrated JPEG CODEC
8.3 Video Registers
Video Control Register
0x030 type default 7 Video8 R/W X 6 Range - X 5 0 - X 4 0 - X 3 FIDet R/W X 2
FIVedge
Scaling Register Address 0x030
1 FIExt R/W X 0
SyncMstr
Address: 0x032
6 0 - X 5 0 - X 4 0 - X 3 0 - X 2 VScale R/W X 0 HScale R/W R/W X X 1
0x032 type default
7 0 - X
R/W X
R/W 0
SyncMstr: The ZR36060 is the Master or Slave of the Video syncs. 0 - Slave of Video syncs 1 - Master of Video syncs FIExt: Field detection by external pin or decoding from H/VSYNC. 0 - Field detection (even/odd) by latching HSYNC with VSYNC 1 - Detect even/odd via the dedicated FI pin FIVedge: Defines the start of a video field at the leading or trailing edge of VSYNC (affects the reset point for the vertical counters, the FI signal state change, the next field search upon START, and DATERR assertion when VSYNC arrives before end of field compression). 0 - Leading edge of VSYNC 1 - Trailing edge of VSYNC FIDet: Detection/meaning of correct field (after FIExt parameter). 0 - ODD fields: FI is low, or VSYNC latches the HSYNC pulse 1 - ODD fields: FI is high, or VSYNC latches the middle of a line Range: Defines the full-scale range of the video bus pixels data in decompression. Has no effect in compression. 0 - Pixel values are full-scale with 256 levels. 1 - Pixel values limited between [16,235] (per CCIR 60.) Video8: Defines the video bus width. 0 - 16-bit video bus 1 - 8-bit video bus
HScale: Horizontal down or up scaling (depending on compression/ decompression) 00b - No scaling 01b - 2:1 scaling ratio, with fixed horizontal filtering 10b - 4:1 scaling ratio, with fixed horizontal filtering 11b - Not used VScale: Vertical down or up scaling (depending on compression/decompression) 0 - No scaling 1 - In compression, only even indexed lines (0,2,..) are processed. In decompression, duplicate video lines
Background Color Registers
7 0x033 0x034 0x035 type default 6 5 4 3 BackY[7:0] BackU[7:0] BackV[7:0] R/W X
Address: 0x033 - 0x035
2 1 0
BackX: Y, U, V components for the background color (used only in decompression)
Video Polarity Register
7 0x031 type default
VCLKPol
Address 0x031
5 PoePol R/W X 4
SImgPol
R/W X
6 PValPol R/W X
R/W X
3 BLPol R/W X
2 FIPol R/W X
1 HSPol R/W X
0 VSPol R/W X
VSPol: Polarity for the VSYNC signal (note that this parameter is totally independent of the FIVedge parameter) 0 - Sync pulse is active low 1 - Sync pulse is active high HSPol: Polarity for the HSYNC signal 0 - Sync pulse is active low 1 - Sync pulse is active high FIPol: Polarity for the FIeld Identification signal 0 - ODD fields: FI is low 1 - ODD fields: FI is high BLPol: Polarity for the BLANK signal 0 - BLANK area is active low 1 - BLANK area is active high SImgPol: Polarity for the SUBIMG signal 0 - SUBIMG is low before SVStart, SHStart and after SVEnd, SHEnd 1 - SUBIMG is high before SVStart, SHStart and after SVEnd, SHEnd PoePol: Polarity for the POE signal to permit floating (disabling) of the ZR36060 video bus during decompression: 0 - Disable bus when input is low 1 - Disable bus when input is high PValPol: Polarity for the PVALID signal 0 - Pixels are valid when PVALID is low 1 - Pixels are valid when PVALID is high VCLKPol: Polarity for the VCLK signal (used in 16-bit video width only) 0 - Pixels are valid when VCLK is low 1 - Pixels are valid when VCLK is high
31
Integrated JPEG CODEC
Sync Generator Registers
7 0x036 0x037 0x038 0x039 0x03A 0x03B 0x03C 0x03D 0x03E 0x03F 0x040 0x041 type default 6 5 4 3 Vtotal [15:8] Vtotal [7:0] Htotal [9:8] Htotal [7:0] VsyncSize [7:0] HsyncSize [7:0] BVstart [7:0] BHstart [7:0] BVend [15:8] BVend [7:0] BHend [9:8] BHend [7:0] R/W X
Address: 0x036 - 0x041
2 1 0
Active Area Registers
7 0x042 0x043 0x044 0x045 0x046 0x047 0x048 0x049 type default 6 5 4 3 Vstart [15:8] Vstart [7:0] Vend [15:8] Vend [7:0] Hstart [9:8] Hstart [7:0] Hend [9:8] Hend [7:0] R/W X
Address: 0x042 - 0x049
2 1 0
Parameters used by the internal video sync generator when it is in Master mode (SyncMstr=1). Horizontal measures are in number of VCLKs (1 VCLK = 1 pixel, regardless of t video bus width), from the leading edge of HSYNC. Vertical measures are in number of HSYNCs (1 HSYNC = 1 line), from the leading or trailing edge of VSYNC according to the FIVedge parameter. BLANK signal window parameters are relative to a different horizontal/vertical origin than the SUBIMG and ACTIVE video windows. Vtotal[15:0]: Number of horizontal lines per frame. Writing N indicates that the frame has N+1 total lines. (e.g. - Vtotal = 524, for NTSC, 525 lines per frame) Maximum permitted value is 65535. Htotal[9:0]: Number of total VCLKs (pixels) per line. Write N indicate that the line has N+1 pixels. (e.g. - Htotal = 857, for NTSC-CCIR 858-pixels per line) Maximum permitted value is 768. VsyncSize[7:0]: Length of VSYNC pulse measured in number of lines. Writing N indicates that the sync pulse has N+1 lines. (e.g. - VsyncSize = 5, for 6-lines vertical sync interval) HsyncSize[7:0]: Length of HSYNC pulse measured in number of VCLKs (pixels). Writing N indicates that the sync pulse has N+1 pixels. (e.g. - HsyncSize = 31, for 32-pixels horizontal sync interval) BVstart[7:0]: Length from VSYNC edge to first. non-BLANK line measured in number of lines. Writing N indicates that the first non-BLANK line is line N+1. (e.g. - BVstart = 11, to have the first non-BLANK line on line number 12) BHstart[7:0]: Length from HSYNC leading edge to first non-BLANK pixel measured in number of pixels. Writing N indicates that the first non-BLANK pixel is pixel number N+1. (e.g. - BHstart = 99, to have the first non-BLANK pixel on VCLK number 100) BVend[15:0]: Length from VSYNC edge to last non-BLANK line measured in number of lines. Writing N indicates that the last non-BLANK line is line N. (e.g. BVend = 241, to have the last non-BLANK line on line number 241) BHend[9:0]: Length from HSYNC leading edge to last non-BLANK pixel measured in number of pixels. Writing N indicates that the last non-BLANK pixel is pixel number N. (e.g. - BHend = 720, to have the last non-BLANK pixel on VCLK number 720)
Parameters used to define the `active area' rectangle of the processed video. Master/Slave modes do not affect these parameters. Horizontal measures are in number of VCLKs (1 VCLK = 1 pixel, regardless of the video bus width), from the leading edge of HSYNC. Vertical measures are in number of HSYNCs (1 HSYNC = 1 line), from the leading or trailing edge of VSYNC according to the FIVedge parameter. Vstart[15:0]: Length from VSYNC edge to first active (processed) line measured in number of lines. Writing N indicates that the first active line is line N+1. (e.g. Vstart = 11, to have the first active line on line number 12). Vend[15:0]: Length from VSYNC edge to last active (processed) line measured in number of lines. Writing N indicates that the last line is line N. (e.g. - Vend = 241, to have the last line on line number 241). Maximum permitted value for (Vend - Vstart) is 32768. Hstart[9:0]: Length from HSYNC leading edge to first active (processed) pixel measured in number of pixels. Writing N indicates that the first active pixel is pixel number N+1. (e.g. - Hstart = 99, to have the first active pixel on VCLK number 100). Hend[9:0]: Length from HSYNC leading edge to last active (processed) pixel measured in number of pixels. Writing N indicates that the last active pixel is pixel number N. (e.g. - Hend = 720, to have the last active pixel on VCLK number 720). Maximum permitted value for (Hend - Hstart) is 768.
32
Integrated JPEG CODEC
SUBIMG Window Registers
7 0x04A 0x04B 0x04C 0x04D 0x04E 0x04F 0x050 0x051 type default 6 5 4 3 SVstart [15:8] SVstart [7:0] SVend [15:8] SVend [7:0] SHstart [9:8] SHstart [7:0] SHend [9:8] SHend [7:0] R/W X
Address: 0x04A - 0x051
2 1 0
markers SOF and SOS, and whichever optional markers are specified in the Markers Enable register. Note that the starting location of each marker segment in the internal memory is fixed, but the length and the content of each marker segment may vary. The host does not have to program any of the marker segments in order to decompress an image bitstream that contains all the necessary tables. If the bitstream is in the abbreviated format and lacks one or more tables, the host must program the appropriate tables in the internal memory, and issue a Load command before starting to decompress a sequence of images that use the same tables.
Parameters used to define the `sub-image window' rectangle of the video. Master/ Slave modes do not affect these parameters. Horizontal measures are in number of VCLKs (1 VCLK = 1 pixel, regardless of the video bus width), from the leading edge of HSYNC. Vertical measures are in number of HSYNCs (1 HSYNC = 1 line), from the leading or trailing edge of VSYNC according to the FIVedge parameter. SVstart[15:0]: Length from VSYNC edge to first subimage line measured in number of lines. Writing N indicates that the first subimage line is line N+1. (e.g. SVstart = 11, to have the first subimage line on line number 12). SVend[15:0]: Length from VSYNC edge to last subimage line measured in number of lines. Writing N indicates that the last line is line N. (e.g. - SVend = 241, to have the last line on line number 241). Maximum permitted value for (SVend - SVstart) is 32768. SHstart[9:0]: Length from HSYNC leading edge to first subimage pixel measured in number of pixels. Writing N indicates that the first subimage pixel is pixel number N+1. (e.g. - SHstart = 99, to have the first subimage pixel on VCLK number 100). SHend[9:0]: Length from HSYNC leading edge to last subimage pixel measured in number of pixels. Writing N indicates that the last subimage pixel is pixel number N. (e.g. - SHend = 720, to have the last subimage pixel on VCLK number 720). Maximum permitted value for (SHend - SHstart) is 1024.
Table 4: ZR36060 JPEG Markers
Address 060 Content SOF0 Value FF Description Start Of Frame marker (FFC0). This segment contains 17 bytes that define the 3 Y,U,V components of the MCU. Is used both in compression and decompression.
061 062 063 064 065 066 067 068 069 06A 06B 06C 06D 06E 06F 070 071 072 ... 07A
SOF0 LEN_H LEN_L P Y_H Y_L X_H X_L Nf CY HY,VY TqY CU HU,VU TqU CV HV,VV TqV ... SOS
C0 00 11 8 Precision (8 bits) Number of lines in the active area (must always equal Vend - Vstart) Length of this segment (without the marker)
8.4 JPEG Marker Segments
The following table shows the mapping of all JPEG markers in the ZR36060 internal memory. The Value column contains common values (hexadecimal) used when compressing/decompressing YUV 4:2:2 format images. There are no default values since all the markers are contained inside the internal RAM, therefore the user must pre-load the correct values before operating the ZR36060. In compression the marker segments data appears in the compressed image bitstream. Inclusion of optional marker segments is controlled by the Markers Enable register. In decompression, the marker segments contained in the compressed bitstream are automatically written by the ZR36060 into the appropriate internal memory locations. At the end of a compression, the host can read them if so desired. The marker segments in the Internal Memory have exactly the same syntax as the marker segments specified in the JPEG standard. These segments are: SOF, SOS, DRI, DQT, DHT, APP, and COM. The SOI, EOI and RST markers are supported automatically by the ZR36060. Before starting to compress a sequence of images, the host must program the appropriate marker segments in the internal memory, and issue a Load command to load them. Only the markers actually used need to be programmed: the required
Number of pixels in the active area (must always equal Hend - Hstart)
3 0 21 0 1 11 1 2 11 1
Number of Color Components (YUV = 3 components) ID for the Y Component Number of appearances of Y in MCU, horizontally and vertically Quantization table ID for Y ID for the U Component Number of appearances of U in MCU, horizontally and vertically Quantization table ID for U ID for the V Component Number of appearances of V in MCU, horizontally and vertically Quantization table ID for V Unused
FF
Start Of Scan marker (SOS). Contains the Huffman table IDs to use with each Y,U,V component in the MCU.
07B 07C
SOS LEN_H
DA 00 Length of this segment (without the marker)
33
Integrated JPEG CODEC
Table 4: ZR36060 JPEG Markers (Continued)
Address 07D 07E 07F 080 081 082 083 084 085 086 087 .... 0C0 ..... DRI FF Content LEN_L Ns CY TYd,TYa CU TUd,TUa CV TVd,TVa Value C 3 0 00 1 11 2 11 00 3F 00 Unused Define Restart Interval. This six-byte segment is used in both the encoding and decoding modes. Number of Components in this scan ID for the Y Component Huffman DC, AC table selections for Y Component ID for the U Component Huffman DC, AC table selections for U Component ID for the V Component Huffman DC, AC table selections for V Component Constant 3-byte data to indicate end of scan information Description
Table 4: ZR36060 JPEG Markers (Continued)
Address 1D8... Content Value Description Typical DHT segment tables data: 00 00 01 05 01 01 01 01 01 01 00 00 00 00 00 00 00 00 01 02 03 04 05 06 07 08 09 0A 0B 01 00 03 01 01 01 01 01 01 01 01 01 00 00 00 00 00 00 01 02 03 04 05 06 07 08 09 0A 0B 10 00 02 01 03 03 02 04 03 05 05 04 04 00 00 01 7D 01 02 03 00 04 11 05 12 21 31 41 06 13 51 61 07 22 71 14 32 81 91 A1 08 23 42 B1 C1 15 52 D1 F0 24 33 62 72 82 09 0A 16 17 18 19 1A 25 26 27 28 29 2A 34 35 36 37 38 39 3A 43 44 45 46 47 48 49 4A 53 54 55 56 57 58 59 5A 63 64 65 66 67 68 69 6A 73 74 75 76 77 78 79 7A 83 84 85 86 87 88 89 8A 92 93 94 95 96 97 98 99 9A A2 A3 A4 A5 A6 A7 A8 A9 AA B2 B3 B4 B5 B6 B7 B8 B9 BA C2 C3 C4 C5 C6 C7 C8 C9 CA D2 D3 D4 D5 D6 D7 D8 D9 DA E1 E2 E3 E4 E5 E6 E7 E8 E9 EA F1 F2 F3 F4 F5 F6 F7 F8 F9 FA 11 00 02 01 02 04 04 03 04 07 05 04 04 00 01 02 77 00 01 02 03 11 04 05 21 31 06 12 41 51 07 61 71 13 22 32 81 08 14 42 91 A1 B1 C1 09 23 33 52 F0 15 62 72 D1 0A 16 24 34 E1 25 F1 17 18 19 1A 26 27 28 29 2A 35 36 37 38 39 3A 43 44 45 46 47 48 49 4A 53 54 55 56 57 58 59 5A 63 64 65 66 67 68 69 6A 73 74 75 76 77 78 79 7A 82 83 84 85 86 87 88 89 8A 92 93 94 95 96 97 98 99 9A A2 A3 A4 A5 A6 A7 A8 A9 AA B2 B3 B4 B5 B6 B7 B8 B9 BA C2 C3 C4 C5 C6 C7 C8 C9 CA D2 D3 D4 D5 D6 D7 D8 D9 DA E2 E3 E4 E5 E6 E7 E8 E9 EA F2 F3 F4 F5 F6 F7 F8 F9 FA .... APP FF Unused Application marker segment. Limited to 64-byte maximum length including the marker Can be En
0C1 0C2 0C3 0C4 0C5 .... 0CC 0CD 0CE 0CF 0D0...
DRI LEN LEN RI_H RI_L ..... DQT DQT LEN LEN
DD 00 04 0 8 Unused FF DB 0 84 Typical DQT segment length, with two tables Define Quantization Tables. 381 382 383 ... 3C0 APP LEN_H LEN_L .... COM Length of Restart Interval in MCU units. .... 380
E0 00 3E
Contents of the APP segment FF Comment marker segment. Limited to 64-byte maximum length including the marker In compression, if this byte is programmed to En instead of FE, it is possible to include a second APP segments in the bitstream instead of COM
Typical DQT segment tables data: 00 10 0B 0C 0E 0C 0A 10 OE OD OE 12 11 10 13 18 28 1A 18 16 16 18 31 23 25 1D 28 3A 33 3D 3C 39 33 38 37 40 48 5C 4E 40 44 57 45 37 38 50 6D 51 57 5F 62 67 68 67 3E 4D 71 79 70 64 78 5C 65 67 63 01 11 12 12 18 15 18 2F 1A 1A 2F 63 42 38 42 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 .... DHT DHT LEN LEN FF C4 1 A2 Typical DHT segment length, with 2 DC and 2 AC tables 65 more bytes for optional third table, the remainder unused Define Huffman Tables.
3C1
COM
FE
3C2 3C3 ...3FF
LEN_H LEN_L ....
00 3E Contents of the COM segment (End of ZR36060 internal memory)
.... 1D4 1D5 1D6 1D7
34
Integrated JPEG CODEC
9.0 ELECTRICAL CHARACTERISTICS ABSOLUTE MAXIMUM RATINGS
Storage Temperature ........................................ -65C to +150C Supply Voltage (Vdd)...........................................-0.5 V to +5.0 V DC Output Voltage ........................................... -0.5 V to Vdd+0.5 DC Input Voltage .................................................-0.5 V to +6.0 V DC Output Current.......................+-20 mA/output, Max. 200 mA DC Input Current ..............................................-30 mA to +5 mA Power Dissipation ............................................ 1 W @ 35.5 MHz
Note: Stresses above these values may cause permanent device failure. Functionality at or above these limits is not implied. Exposure to absolute maximum ratings for extended periods may affect device reliability.
OPERATING RANGE
Temperature............................................................0C to +70C Supply Voltage............................................................ 3.3 V 5%
DC CHARACTERISTICS
Table 5: DC Input Characteristics
Symbol VIL VIH ILI CIN ICC ISC
s
Parameter Input Voltage Low Input Voltage High Input leakage current Input Capacitance Power Supply Current Stand-by (SLEEP) current
Min -0.3 2.0
Max 0.8 5.5
Unit V V A pF mA mA
Test Conditions
10
10 230 15
@ 30 Mhz
Table 6: DC Output Characteristic
Symbol VOL VOH ILO COUT Output Voltage Low Output Voltage High Output Leakage Current Output Capacitance 2.4 Parameter Min Max 0.4 Unit V V A pF Test Conditions IOL = 2 mA IOH = -400 mA
10
10
35
Integrated JPEG CODEC
AC TIMING SPECIFICATIONS
Table 7: AC Video Bus Input Timing
Symbol FVCLKx2 TV2P TCLK Parameter VCLKx2 Frequency VCLKx2 Period Internal Clock Period Min 22.2 33.3 Max 30 45 Unit MHz ns TV2P == 2 * TCLK Internal PLL multiplies the VCLKx2 freq. by 2 Used as a reference variable for other AC parameters. 3 3 6 0 ns ns ns ns Comments 40% to 60% duty cycle
TV2T TVT TVIS TVIH
VCLKx2 Rise/Fall Transition VCLK Rise/Fall Transition Video Bus Input Setup Video Bus Input Hold
tV2P VCLKx2
tV2T
tV2T
tVIS VCLK
tVIH
tVIS INPUTS
tVIH
Note: 1. In this diagram VCLKPol = 0. 2. 16-bit interface inputs are sampled during VCLKx2 rising edges enabled by VCLK. 3. 8-bit interface inputs are sampled during all VCLKx2 rising edges.
Figure 41. Video Bus Input Timing
Table 8: AC Video Bus Output Timing
Symbol TVBO TVBO8 Parameter Video Bus Output Delay (16-bit) Video Bus Output Delay (8-bit) Min TCLK - 1 0.5TCLK - 1 Max TCLK + 10 0.5TCLK + 10 Unit ns ns 50pf load 50pf load Comments
tCLK VCLKx2
VCLK
tVBO Video Output (16-bit) tVBO8 Video Output (8-bit) tVBO8
tVBO
Figure 42. Video Bus Output Timing
36
Integrated JPEG CODEC
Table 9: AC Host Interface Timing
Symbol tCAS tCAH tWDUR tWACK tDS tDH tRDUR tRACK tOPD tOH tREC tAH Parameter CS/ ADDR[1:0] setup to WR or RD falling edge CS/ ADDR[1:0] hold from WR or RD rising edge WR minimum strobe pulse width WR low to ACK assertion (low) Input Data Setup to WR rising edge Input Data Hold from WR rising edge RD minimum strobe pulse width RD low to ACK assertion (low) RD low to output data valid Output Data Hold RD rising edge to data float WR or RD rising edge to next falling edge of WR or RD WR or RD rising edge to ACK rising edge tCLK 3 * tCLK 25 Min 5 5 3 * tCLK 3 * tCLK 5 2 5 * tCLK 5 * tCLK 5 * tCLK + 10 4 * tCLK + 10 2 * tCLK + 10 3 * tCLK + 10 Max Unit ns ns ns ns ns ns ns ns ns ns ns ns 50 pF 50 pF 50 pF Comment
tCAS CS
tCAH
tCAS
tCAH
ADDR[1:0]
tWDUR WR
tREC RD
tRDUR
tWACK ACK
tAH
tRACK
tAH
tDS DATA[7:0] Host Data Valid
tDH
tOPD ZR36060 Data Valid
tOH
Figure 43. Host Interface Timing
37
Integrated JPEG CODEC
Table 10: AC Code Slave Interface Timing
Symbol tCAS tCAH tDUR tACK tDS tDH tOPD tOH tREC tAH Parameter CS / ADDR[1:0] setup to WR or RD falling edge CS / ADDR[1:0] hold from WR or RD rising edge WR or RD minimum strobe pulse width 8-bit mode: 16-bit mode: WR or RD low to ACK assertion (low) Input Data Setup to WR rising edge Input Data Hold from WR rising edge RD low to output data valid Output Data Hold RD rising edge to data float WR or RD rising edge to next falling edge of WR or RD WR or RD rising edge to: - ACK rising edge - CBUSY falling edge - EOI falling edge tCLK 3 * tCLK 25 Min 5 5 3 * tCLK 4 * tCLK 3 * tCLK 5 2 2 * tCLK + 10 2 * tCLK + 10 3 * tCLK + 10 Max Unit ns ns ns ns ns ns ns ns ns ns ns 50 pF 50 pF 50 pF Comment
tCAS CS
tCAH
tCAS
tCAH
ADDR[1:0]
00
00
tDUR WR
tREC RD
tDUR
tACK ACK
tAH
tACK
tAH
tDS DATA[7:0] CODE[7:0] Host Data Valid
tDH
tOPD ZR36060 Data Valid
tOH
tAH CBUSY EOI
Figure 44. Host Interface Timing
38
Integrated JPEG CODEC
Table 11: AC Code Master Interface Timing
Symbol tCPD tSPD tSH tDPD tDH tDSU tDH tBSU tBH Parameter CCS Propagation Delay COE or CWE Propagation Delay COE or CWE Hold Delay Code Data Propagation Delay Code Data Hold Delay Code Data Input Setup Code Data Input Hold CBUSY Setup CBUSY Hold Min 1 1 0 1 1 10 0 10 0 10 Max 10 10 Unit ns ns ns ns ns ns ns ns ns Load = 50pF Comment Load = 50pF
VCLKx2
tCPD CCS
tCPD
tCPD
tSPD COE
tSH
tSPD CWE
tSH
tBSU CBUSY
tBH
tDSU CODE[7:0]
tDH
tDPD
tDH ZR36060 Data Valid
External FIFO Data Valid
Figure 45. Code Master Interface Timing
39
Integrated JPEG CODEC
10.0 MECHANICAL DATA
Table 12: 100-Pin Quad Flat Pack Pin Assignment
Pin No 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Pin Name GND GND GND UV0 UV1 UV2 UV3 VDD UV4 GND UV5 UV6 VDD UV7 Y0 Y1 GND Y2 Y3 Y4 VDD Y5 Y6 Y7 GND Pin No 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 Pin Name NC VDD GND GND NC NC FI HSYNC VSYNC VDD BLANK PVALID SUBIMG POE SLEEP GND VCLKX2 VDD NC GND VCLK VDD GND GND CWE Pin No 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 Pin Name COE CCS GND GND CODE7 CODE6 CODE5 CODE4 VDD CODE3 GND CODE2 VDD CODE1 CODE0 DATA7 DATA6 GND DATA5 DATA4 VDD DATA3 DATA2 DATA1 GND Pin No 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 Pin Name DATA0 VDD GND GND NC COMP ACK CBUSY VDD RESET ADDR1 ADDR0 CS RD WR GND EOI VDD END DATERR RTBSY JIRQ START VDD FRAME
40
Integrated JPEG CODEC
Pin 1 index mark, notched corner, or both
100
FRAME VDD START JIRQ RTBSY DATERR END VDD EOI GND WR RD CS ADDR0 ADDR1 RESET VDD CBUSY ACK COMP 81
1 GND GND GND UV0 UV1 UV2 UV3 VDD UV4 GND UV5 UV6 VDD UV7 Y0 Y1 GND Y2 Y3 Y4 VDD Y5 Y6 Y7 GND NC VDD GND GND NC 30
80 NC GND GND VDD DATA0 GND DATA1 DATA2 DATA3 VDD DATA4 DATA5 GND DATA6 DATA7 CODE0 CODE1 VDD CODE2 GND CODE3 VDD CODE4 CODE5 CODE6 CODE7 GND GND CCS COE 51
ZR36060
(TOP VIEW)
31 NC FI HSYNC VSYNC VDD BLANK PVALID SUBIMG POE SLEEP GND VCLKX2 VDD NC GND VCLK VDD GND GND CWE
50
41
Integrated JPEG CODEC
.941 .015 (23.90 .40)
.782 .010 (20.00 .20)
TOP VIEW
.012 .004 (.30 .10)
.0256 TYP (.65 .15)
.551 .008 (14.00 .20)
.007 +.0015/-.003 (.18 +.04/-.08)
Seating Plane .015 +.005/-.015 (.38 +.13/-.38) .031 .008 (.80 .20) .705 .015 (17.90 .40)
.006 (.15)
.118 .014 (3.00 .35)
NOTE: Principal dimensions in inches, dimensions in brackets in millimeters.
42
Integrated JPEG CODEC
NOTES
43
Integrated JPEG CODEC
ORDERING INFORMATION
ZR 36060 PQ C
PACKAGE PQ - Plastic Quad Flat Pack (EIAJ) SCREENING KEY PACKAGE PART NUMBER PREFIX SCREENING KEY C - 0C to +70C (VCC = 4.75V to 5.25V)
SALES OFFICES
s U.S. Headquarters Zoran Corporation 2041 Mission College Blvd Santa Clara, CA 95054 USA Telephone: 408-986-1314 FAX: 408-986-1240 s Israel Design Center Zoran Microelectronics, Ltd. Advanced Technology Center P.O. Box 2495 Haifa, 31024 Israel Telephone: 972-4-8551-551 FAX: 972-4-8551-550
The material in this data sheet is for information only. Zoran Corporation assumes no responsibility for errors or omissions and reserves the right to change, without notice, product specifications, operating characteristics, packaging, etc. Zoran
Corporation assumes no liability for damage resulting from the use of information contained in this document.
DS36060-0297

▲Up To Search▲

Price & Availability of ZR36060

	To Download ZR36060 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .